(cutting out unnecessary text to reduce clutter...)
Mikael Nilsson wrote:
[snip]
>
>
> Note, I'm now leaving the dc: namespace and *only* talking about
> the dcterms: namespace
>
Agreed. That was my understanding, too
> A) dcterms:title and description. Looking at the draft, they have been
> given a range of "rdfs:Resource". That is, literals are allowed. This,
> naturally, has to do with the fact that a string is actually a useful
> title/description. So you should not have to worry there.
>
Yep. Although the question is whether an explicit range restriction for
a Literal is not a better solution. See below...
> B) dcterms:date. The range of this property is Period. Now, as it
> stands, xsd:date is not a subClassOf Period. However, this has been put
> forward as a possibility.
>
[snip]
>
> Thus, IF xsd:date were made subClassOf dcterms:Period, you could do
>
> dcterms:modified "2007-01-01"^^xsd:date
>
That is *technically* correct. What I mean is that it is certainly
correct in terms of the RDFS syntax and semantics. However, I must admit
I find it counter-intuitive. And I also find a potential pitfall here.
Indeed: I know that DC has not considered using OWL at the moment.
However, it might be a good idea to slightly think a bit ahead: what if
either DC or some other organization would like to use the DC terms in
an OWL, more exactly in an OWL-DL setting? This may sound far fetched at
first glance, but again may not be that impossible. After all, as I
remarked already at some point, the Dublin Core terms have become
ubiquitous on the Semantic Web (you are the victims of your own
success:-), and if people want to build up more formal ontologies, they
may well want to include DC terms.
However... the solution you propose would *not* be correct OWL DL,
because OWL DL does not allow redefining the semantics of the 'core' RDF
terms (and this is what happens with your approach!). Actually, my
previous solution of using owl:unionOf does not work either, because OWL
DL requires a separation of datatype and object properties.
But maybe this is the case, actually, where the rigour of Description
Logic may help in cleaning up the terms... What if the new dcterm
namespace includes some of the properties in duplicate? What I mean,
what about saying: dcterm has a dcterm:modified and
dcterm:modifiedPeriod properties? One could then say
dcterm:modified rdf:type rdfs:Property;
rdfs:range xsd:date.
dcterm:modifiedPeriod rdf:type rdfs:Property;
rdfs:range dcterm:Period.
If one wanted to turn that into OWL-DL aware definitions, it becomes
simple; one just adds
dcterm:modified rdf:type owl:DatatypeProperty.
dcterm:modifiedPeriod rdf:type owl:ObjectProperty.
Thinking about this again, I have the impression that this leads to a
much cleaner modelling. My estimate is (I do not have the numbers at
hand, though) that a vast majority of users would be perfectly content
with the usage of dcterm:modified with the extra bonus of a possible
type checking on the datatype (which is a big plus compared to
dc:modified); this could include the OpenDocument users and many others.
Digital Library users that you were referring to may have to use more
complex terms; they could then use dcterm:modifiedPeriod which would
satisfy their needs.
Is that an impossible avenue to consider?
Just food for thoughts...
Ivan
--
Ivan Herman, W3C Semantic Web Activity Lead
URL: http://www.w3.org/People/Ivan/
PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf
|