Re: RDF Review

>Dear All,
>Jeff and I (mostly Jeff) have looked at the latest RDF MT, in
>particular the Datatypes section. We did not have time for an
>exhaustive review, but here are some comments:

Thanks, guys.

>Regards, Ian
>1. Interpretations
>IP no longer (explicitly) a subset of IR (see defn of RDF simple
>interp in Sec 1.3)? Not sure if this has any impact on OWL (or on RDF
>come to that).

I think not, since the old constraint applies to all RDF (and up) 

>2. Datatypes
>My main impression is that the "datatype clash" in RDF has not
>been defined/explained clearly enough in section 5, which presents the
>datatype interpretation of RDF. Datatype clash is important
>because it is one of *only three inconsistencies* recognized by the
>model theory (see section 5). Until the picture is clear, it is
>difficult to determine how it affects OWL.
>When explaining datatype clash, the semantic doc says
>"If the datatypes in the datatype map D impose disjointness conditions
>on their value spaces, it is possible for an RDF graph to have no
D-interpretation which satisfies it."

Perhaps the wording of this could be improved and expanded a little, I agree.

>However, it is also possible that the problem comes from the lexical
>form, e.g.
><ex:a> <ex:b> "2.5"^^xsd:decimal  (1)
><ex:b> rdfs:range xsd:integer  (2)
>Is this a datatype clash?

Yes, because of the disjointness of xsd:integer and any non-integer 
values in xsd:decimal.

>The only example in section 5 about datatype clash is about typed
>literals, what about the cases that we don't use typed literal. E.g.
><ex:c> rdfs:range xsd:string    (3)
><ex:c> rdfs:range xsd:integer    (4)
><ex:d> <ex:c> _:xxx    (5)
>Is this a datatype clash?

Yes, since the value spaces of the datatypes are disjoint.

>According to the informative entailment
>rules in section 7, it is a datatype clash:
>from (3) and (rdfs3) we have _:xxx rdf:type xsd:string     (6)
>from (4) and (rdfs3) we have _:xxx rdf:type xsd:integer    (7).
>If this is the case, does it mean that the informative part of the
>document implies something that isn't mentioned in the normative


>The above example can be regarded as property inconsistency; similarly
>we can have class inconsistency:
><ex:e> rdfs:subClassOf xsd:integer    (8)
><ex:e> rdfs:subClassOf xsd:string    (9)
>means that ex:e is equivalent to owl:Nothing, and adding
>_:yyy rdf:type <ex:e>    (10)
>leads to ontology inconsistency.

That is true, and I should probably insert some more explanatory text 
to draw attention to these cases. Thanks for shining a light on this 

It may be impossible to make these changes before LC2, as our 
timetable is now extremely tight, but if not then I will undertake to 
insert some explanatory prose during the LC process before 

I think this can reasonably be regarded as editorial changes to the 
exposition, since it only seeks to clarify an existing situation.


IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell

Received on Thursday, 2 October 2003 21:47:35 UTC