W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: around the table on datatypes [ was: Re: datatyping draft 3 (for telecon)]

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 19 Feb 2002 22:12:30 -0600
Message-Id: <p05101407b8985abe4957@[]>
To: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Cc: w3c-rdfcore-wg@w3.org
>>   o Are there any concerns with the proposal
>>     you would like to raise? (What are they?)
>The use of subclass declarations to "switch idioms"; e.g.
>   rdf:type rdfs:subPropertyOf rdfs:dtype .    (section 5, 10)
>   rdfs:range rdfs:subPropertyOf rdfs:drange .  (section 7, 10)
>   rdf:dtype rdfs:range rdfs:Datatype .         (section 10)
>   rdf:drange rdfs:range rdfs:Datatype .        (section 10)
>The problem I foresee is when one wishes to combine information from 
>different sources.

Then the above could be dangerous, since these assertions apply to 
any graph that contains them. Yes, and we should emphasize this 
point. Still, I'm all for letting people live dangerously if they 
want to take the risks upon themselves.

>Suppose some graph A contains some statements:
>   exa:decimalInteger rdf:type rdfs:Datatype .
>   exa:octalInteger rdf:type rdfs:Datatype .
>   exa:octalInteger rdfs:subClassOf exa:decimalInteger .
>   _:a rdf:value "10" .
>   _:a rdf:dtype exa:octalInteger .
>   _:b rdf:value "10" .
>   _:b rdf:dtype exa:decimalInteger .
>where the intent is to define a new datatype class with the same 
>value space as an existing class, but with a different lexical space 
>and lexical-to-value mapping.
>Also, consider graph B, constructed to avoid datatype clashes:
>   rdf:type rdfs:subPropertyOf rdfs:dtype .

I note that this is intrinsically a 'dangerous' option that should 
only be used when there is no possibility of clashing datatypes being 
used. So whoever wrote graph B was making some potentially dangerous 
assumptions, like when I remove the safety guard from my bench saw. I 
know Im taking a risk, but the convenience is worth it.

>   exb:integer rdf:type rdfs:Class .
>   exb:decimalInteger rdf:type rdfs:Datatype .
>   exb:octalInteger rdf:type rdfs:Datatype .
>   exb:octalInteger rdf:type rdfs:Datatype .
>   exb:octalInteger rdfs:subClassOf exb:integer .
>   exb:decimalInteger rdfs:subClassOf exb:integer .
>   _:c rdf:value "10" .
>   _:c rdf:type exb:octalInteger .
>   _:d rdf:value "10" .
>   _:d rdf:type exb:decimalInteger .
>So far, so good.  But consider what happens if these two graphs are 
>combined (merged):

OK, B is about to lose a thumb.

>We end up with a graph that entails the following:
>[From B:]
>   rdf:type rdfs:subPropertyOf rdfs:dtype .
>[From A:]
>   exa:decimalInteger rdf:type rdfs:Datatype .
>   exa:octalInteger rdf:type rdfs:Datatype .
>   exa:octalInteger rdfs:subClassOf exa:decimalInteger .
>   _:a rdf:value "10" .
>   _:a rdf:dtype exa:octalInteger .
>   _:b rdf:value "10" .
>   _:b rdf:dtype exa:decimalInteger .
>Then, from the subclass relationship, we have:
>   _:a rdf:type exa:decimalInteger .
>And from the subproperty assertion:
>   _:a rdf:dtype exa:decimalInteger .
>which has introduced a datatyping conflict.

Right, and predictably so. B was betting that all datatypes were 
consistent, and A proved him wrong  by creating one that wasn't.

>My position here is that it should NEVER be possible to merge two 
>valid RDF graphs and end up with an error or inconsistency of this 

Two reactions to this position.
(1) technically, this graph is a consistent RDF graph. It has a 
datatype clash in it, but that's a problem for the datatype checker, 
not for RDF itself.
(2) If you want to say that datatyping is intrinsic to RDF, then the 
position is untenable. Datatype clashes CAN occur; the world of 
datatypes has genuine differences of opinion in it, and its 
impossible to freely combine datatyping information without running 
the risk of finding such conflicts. There's nothing we can do about 

>  To my mind, the ability to freely merge RD information from various 
>sources is the key to power of RDF -- to combine information from 
>different RDF applications thereby obtaining a new knowledge base 
>that is potentially more than the sum of its parts.

Sure, but there isnt any way to guarantee that this free combination 
is always going to produce a single coherent story, Sometimes, people 
really do disagree. What A and B discovered is that they have a 
difference of opinion.

>I think that information will demonstrate a variation of Metcalfe's 
>law:  the value of information will be exponentially proportional to 
>the number of applications that can create and share it.  RDF is a 
>key to that sharing, IFF information can be freely combined.

But when there can be conflicts, the free combination of information 
can reveal those conflicts. Theres nothing we can do about that: 
there's no point in trying to pass a law that everyone has to agree 
with everyone else.

>This last bit is all assertion-without-proof, but I'm guessing that 
>most people will agree that it's important to be able to merge RDF 
>information from different sources.
>I think this may be a particular case of a wider danger:  if people 
>try to make additional assertions about the RDF core vocabulary, 
>beyond those specified by RDFcore, the result may be that valid 
>information is lost when graphs are combined -- interpretations that 
>should be models are no longer models.

Thats not a loss of information, its a gain. The fewer satisfying 
interpretations, the better. When you have none, then you know that 
something doesnt agree with something else.

>This leads me to think that any attempt to make additional 
>assertions about core RDF vocabulary terms should be regarded as an 
>error, or at least should carry a serious health warning.

I agree that we should post suitable warnings, but I don't see how we 
can legislate a perfect world.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Wednesday, 20 February 2002 00:40:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:10 UTC