On tis, 2007-02-27 at 13:26 +0100, Ivan Herman wrote:
> > 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!).
Can you clarify this last statement? Where do we redefine the semantics
of the core RDF terms?
> Actually, my
> previous solution of using owl:unionOf does not work either, because OWL
> DL requires a separation of datatype and object properties.
Right, that *is* a problem, I can see that too.
>
> 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.
I can see why you would want that, but I am unsure whether that would
actually lead to increased interoperability. I think the solution is to
be found elsewhere.
Maybe the "shortcut" notion in the DC-RDF document is wrong, and we
should rely on literal/datatype ranges for some properties? I don't
knkow.
>
> 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?
I think a doubling of the number of terms for technical reasons is
rather impossible, yes... :-)
/Mikael
>
> Just food for thoughts...
>
> Ivan
>
--
<[log in to unmask]>
Plus ça change, plus c'est la même chose
|