Mikael Nilsson wrote:
> 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?
>
>
I may not have used the right terminology here, sorry. In OWL DL,
datatypes are strictly separated from OWL classes. The
xd:data subClassOf YourOwnClass
violates that separation. Put it another way, you cannot express such
statement in traditional Description Logic, where datatypes are strictly
'outside' the core subject of discourse.
>>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.
>
I am happy if there is one...:-) But I do not see any at the moment.
> 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.
>
I am not sure what you mean here. Do you mean that in some cases you
would define extra XML Schema datatypes for ranges? That may work, but
somehow I am not sure it would work for all of them.
>
>>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... :-)
>
Why? I am just curious... We may not have to duplicate *all* predicates
(I have not checked, though)
Ivan
> /Mikael
>
>
>>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
|