Thanks for the very good summaries, Andy.
I personally feel the consensus on the use of RDF resources as the
values of DC properties will be a real improvement to the semantical
situation with DC RDF metadata.
I have two comments, both complex...
The first is a general insight that Roland and I had in a discussion in
Seattle. The problem is this: if you start using RDF resources as values
of the DC properties, you are introducing new types of items into your
data. These types are of kinds like "entity", "date", "title" (or maybe
"natural language string"). LOM has such types, and it's actually very
helpful in the RDF modeling.
We discussed the well-known fact that when building a database, you
start with defining the types (=tables), and then go on to defining the
properties of these types of objects.
But in DC, these types do not exist. The only kind of types that are in
the DCMI type vocabulary are the different types the resource itself can
have, not the types of the typical *values* of the properties. The
conclusion here could be that DC lacks a project defining some of these
types.
The second comment has to do with element encodings. If we now are going
to look closely at how DC is encoded in RDF, and we agree that resources
should be used as values, how do we represent element encodings?
Using simple semi-N3 notation for some RDF, a Simple DC date property
currently looks like
a)
<res1> <dc:date> "1999-03-13".
In qualified DC, the current recommendation for a W3CDTF-encoded date is
b)
<res1> <dc:date> _:xxx
_:xxx <rdf:type> <dcterms:W3CDTF>
_:xxx <rdf:value> "1999-03-13"
Given that we want to start using resources always for values, the
unqualified example would now look like:
c)
<res1> <dc:date> _:xxx
_:xxx <rdf:value> "1999-03-13"
I now see at least two ways of adding an element encoding to this
construct. The first is exactly b), that is, adding a new <rdf;type>.
Note how the simple and qualified versions are 100% compatible (great!).
On the other hand, we have discussed if RDF datatypes are going to be
introduced in the qualified DC encoding. So there's another possiblity:
d)
<res1> <dc:date> _:xxx
_:xxx <rdf:value> "1999-03-13"^^<dcterms:W3CDTF>
Note how this is *also* 100% compatible with the unqualified version. Of
course, we should probable just map W3CDTF to to the XML Schema "date"
datatype (or datetime? I'm no expert, help!). So we would have
e)
<res1> <dc:date> _:xxx
_:xxx <rdf:value> "1999-03-13"^^<xsd:date>
Looks good, eh? Is e) how we want to represent element encodings? For
all properties or only for some? Or is using the RDF datatype construct
just something outside the scope of DC, and we should stay with b)?
My opinions:
e) looks really good. I'd love to see that. However, I feel the lack of
a typing of the resource. I'd like it to be a <dc:Date> or something
like that, as per the previous comment...
b) does *not* look good to me. The resource is *not* a W3CDTF object.
The resource is a "date", nothing else. The *string literal* is in
W3CDTF format, not the resource.
However, for <dc:subject> encodings, look at:
f)
<res1> <dc:subject> _:yyy
_:yyy <rdf:type> <dcterms:MeSH>
_:yyy <rdf:value> "A01.34"
_:yyy <rdfs:label> "Abdomen"
In this case, the resource (_:yyy) might actually *be* a Medical Subject
Heading, so the current encoding (that is, the b) version) is maybe the
right one. So I'm not sure which way is right.
In any case, it would be really great if we could solve some of these
issues.... I want to use the constructs in the LOM RDF binding :-)
Any opinions?
/Mikael
--
Plus ça change, plus c'est la même chose
|