This is not exactly what I meant. EAD, MODS, MARCXML and DC are different and I do not want to mix them. Also putting ead within the dc:description is not something I proposed.
What we will do is use a stylesheet for the presentation of a number of elements that can be simple DC, qualified DC and some elements from our apllication profile. We will neglect elements that are not in the application profile, but still display the ones that we do recognize. We will allow our data providers to add elements for local use without declaring the response invalid. We will not use a schema but use the application profile to agree on the metadata elements that we expect in the record. We will consider dc:title as title, regardless of what scheme is being used.
We will use different SRU-base-urls for SRU-compatible and local versions of our server and clients, but I wanted to share our approach with respect to the DC and recordSchema with the other subscribers of this list as I found this approach promising and powerfull.
Theo
>>> [log in to unmask] 09-12-02 12:27 >>>
> So my proposal is to use recordsSchema DC as a global name for all
> DC-based application profiles. The servers are allowed to add elements
> additional to simple DC and the clients just ignore the terms that they
> don't understand. When additional namespaces are involved the server
> includes the namespace declarations in the response at the level of the
> SearchRetrieveResponse tag (rather not for every individual tag).
Then we'll get things like:
<dc:description>
<ead:ead>
<ead:eadheader>
<ead:eadid> </ead:eadid>
...
</ead:ead>
<dc:description>
rather than real DC.
> The use of a "real" recordScheme makes sense for those clients that are
> going to validate the responses. Are clients going to validate the
It makes more sense than this. If I have display stylesheets for MarcXML,
EAD, DC and my own local schemas, then I need to know which one it is.
Even if it's DC + metadata I still need to know that I should use the DC +
metadata stylesheet.
> RDF- schema, application profile) but we should use global names in the
> recordSchema parameter to allow for different schemas without becoming
> ininteroperable.
As soon as you have one amorphous pool of record schemas lumped under one
heading with no way to distinguish them, it becomes uninteroperable as you
have no way of knowing how to process it.
> What is the opinion on this?
Not feasable. At least the 15 DC, but unlimited number of other elements.
And you could include zero DC elements.
Rob
--
,'/:. Rob Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
I L L U M I N A T I
|