Carl writes...
> This, as a matter of fact, is exactly the type of situation as we
> re-consider our "core metadata set" for the
> (http://www.openarchives.org). We need an element that
> expresses simple
> "title" semantics, and we might as well use the title element from the
> DC namespace for this. We also need another element with meaning
> "miscellaneous comments about this entry" which doesn't fit
> cleanly into
> the DCES namespace, so we plan to mix that in our application profile.
>
> In this context, however, the problem I raised earlier
> exists. We want
> more expressive "creator semantics" including affiliation
> which doesn't
> match the semantics of the DC "creator" element. So, do we have a DC
> creator element that co-exists with a more expressive OAI creator
> element?
I think we discussing here only a small finite set of possibilities. Which
of these possibilities one would use depends on the particular goals of any
project. I've tried to capture this set as a exercise to a) see if it is
indeed finite and b) to demonstrate how this might be accomplished in
XML/RDF.
Ok... here goes:
1) Use established semantics
In a RDF schema located at http://purl.org/dc/elements/1.1/
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/creator">
<rdfs:label>Creator</rdfs:label>
<rdfs:comment>An entity primarily responsible for making the content of the
resource.</rdfs:comment>
</rdf:Property>
And in the metadata instance data:
<dc:creator>Carl Lagoze</dc:creator>
2) Use new independent semantics
In a RDF schema located at http://www.openarchives.org
<rdf:Property rdf:about="http://www.openarchives.org/vocab/author">
<rdfs:label>Author</rdfs:label>
<rdfs:comment>An openarchives author.</rdfs:comment>
</rdf:Property>
And in the metadata instance data:
<oa:author>Carl Lagoze</oa:author>
3) Use new semantics (but relate to existing semantics)
In a RDF schema located at http://www.openarchives.org
<rdf:Property rdf:about="http://www.openarchives.org/vocab/author">
<rdfs:label>Author</rdfs:label>
<rdfs:comment>An openarchives author.</rdfs:comment>
<!-- define refinement relationship between oa:author and dc:creator -->
<rdfs:subPropertyOf rdf:resource="http://purl.org/dc/elements/1.1/creator"
/>
</rdf:Property>
And in the metadata instance data:
<oa:author>Carl Lagoze</oa:author>
4) Place additional contraints on existing semantics
In a RDF schema located at http://www.openarchives.org
<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/creator">
<!-- define constraint on dc:creator ... value is a Person -->
<rdfs:range rdf:resource="http://www.openarchives.org/vocab/Person" />
</rdf:Property>
<rdfs:Class rdf:about="http://www.openarchives.org/vocab/Person">
<rdfs:label>Person</rdfs:label>
<rdfs:comment>A Person</rdfs:comment>
<rdfs:Class>
<rdfs:Property rdf:about="http://www.openarchives.org/vocab/name">
<rdfs:label>Authors Name</rdfs:label>
<rdfs:domain rdf:resource="http://www.openarchives.org/vocab/Person">
</rdfs:Property>
<!-- declare other properties for email and affiliation in a similar fashion
-->
And in the metadata instance data:
<dc:creator>
<oa:Person>
<oa:name>Carl Lagoze</oa:name>
<oa:email>[log in to unmask]</oa:email>
<oa:affiliation>Cornell</oa:affiliation>
</oa:Person>
</dc:creator>
6) Place additional contraints on new semantics
(similar to #5)
Having done this, I'm in agreement with Jane that this in essence just
indeed more data. I think however a real benefit of these application
profiles is with the actual description and management of these schemas.
Agreeing on both a common way of effectively reusing existing and/or
defining new semantics and then *describing* these profiles in such that
they can be effectively located and utilized is a huge benefit to all
metadata communities.
Or to echo Pricilla's point "It doesn't seem much of a big deal to me to
call it an application profile. I'm actually very interested in being able
to see the application profiles adopted by other implementations."
--eric
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|