On tis, 2007-02-13 at 09:47 +0000, Ivan Herman wrote:
> Third mail from a RDF geek...
>
> I understand there is a subtle complication between the DC abstract model
> and RDF for properties. In DC-Text syntax, one can say:
>
> DescriptionSet (
> Description (
> ResourceURI ( <http://dublincore.org/pages/home> )
> Statement (
> PropertyURI ( dc:publisher )
> ValueURI ( <http://example.org/agents/DCMI> )
> ValueString ( "Dublin Core Metadata Initiative" )
> )
> )
>
> ie, a property *may* have a string value *and* a URI at the same time, so to
> say. The way I would translate that into RDF is something like
>
> dc:publisher [
> # maybe some type information would be in order here
> rdf:value "Dublin Core Metadata Initiative";
> dc:somepropertyhere <http://example.org/agents/DCMI>.
> ].
Well, except the Value URI will be the uri of the object node (object of
the dc:publisher property)
>
> The caveat is when one wants to define the range of the dc:publisher.
> Indeed, this should be defined as a union, namely a union of a literal *and*
> some other type that is used above. Alternatively, the range has to stay a
> general resource, ie, nothing is really said about the range.
>
> Being a bit of an outsider to the core DC discussions, this is all fine with
> me, but it should be explicitly said and documented...
>
> (dc:publisher may be a wrong example here; it seems that the new document
> for ranges defines its range to be an Agent, ie, no direct Literal is
> allowed anyway. But the issue may come up for other properties...)
The intention of the new domains and ranges indeed tries to address this
very problem - DCMI is moving away from "Literal or resource" to a more
precise range, relying on rdf:value to provide value strings.
So, this should be read together with the domains/ranges document, AND,
http://dublincore.org/documents/dc-rdf/
which is still not fully up-to-date with these DCAM modifications, but
gives you an idea of the direction.
In short, we want DC to fully interoperate in an RDF world, while still
being just as useful in other contexts (OAI etc),
/Mikael
>
--
<[log in to unmask]>
Plus ça change, plus c'est la même chose
|