We are starting to use MGEG21/DIDL for compound objects. We may derive
from the metadata (obtained from the index is DC) whether the object is
a compound object and then retrieve it out of the scope of the search
and retieve application. An alternative to this is an extraRecordData
extension indicating which formats are available for a specific record
because different metadat formats are mixed in our index. Anyway the
client has a limited choice for metadata formats that differs per object
and can this cannot be expressed in explain.
I will solve this in my own way but I mention it as an actual use case
which might help in discussing generic solutions for real use cases.
PS. We seem to have problems with SMPT, so you might receive two
messages that were sent from my home 40 hours agoo.
>>> [log in to unmask] 12-08-2005 13:01 >>>
In terms of OAI, Herbert and co at Los Alamos have done interesting
in returning MPEG21/DIDL documents as the "metadata" record, so the
can be argued the other way as well.
On Fri, 12 Aug 2005, Matthew J. Dovey wrote:
>> If the intention is to include properties describing the
>> metadata record
>> (REC), then perhaps it might be better for SRW/SRU to adopt
>> the approach
>> taken by OAI PMH and place this information in a record "header"
>> separate from the metadata.
>This doesn't necessarily work in all cases - I think I did give the
>learning object repository example where we potentially might return
>learning object, learning object metadata and learning object
>metadata (e.g. a REC record for the metadata). At present we *are*
>using different transactions (requesting different recordSchema)
>depending on which we want back, and don't (yet) have a real
>to get all back in a single response.
>> This would be a useful place to park other types of data we haven't
>> considered yet, for example Rights Data applying to the
>> metadata record.
>The issue is we could add such a header - but in many ways we are
>duplicating what other (and possible better) schemas such as METS,
>MPEG21 etc. already do.
>Also adding the header does not necessarily address the other
>requirement - which is someone who *is* using a container schema such
>METS may wish to be able to request what schemas are contained within
>that container (admittedly it isn't yet clear whether this is a real
>requirement now or just anticipation of a future one).