RDF Semantics: corrections(was: Re: RDF Semantics: two issues, connected to OWL)

>On Fri, 2003-12-19 at 17:59, pat hayes wrote:
>>  [...] So I accept that this addition to
>>  the text would be an improvement, I do not feel that this is worth,
>>  as it were, stopping the presses for (even if the presses could be
>>  stopped, which they cannot at this stage.)
>
>The Proposed Rec has gone out, but review of that document is
>in order thru 19Jan.

Ah, I had not realized that. OK....

>Does anybody feel energized to start a new thread,

Take this as the new thread.

-----

My understanding at present is that there is one outright error in 
the document, an editing slip: the statement of the  RDFS entailment 
lemma in appendix A should read the same as the one in the text:
"rule lg" -> "rules lg, gl"
with appropriate links, of course.

The remaining comments from Herman are concerned with the way that 
D-interpretations are defined.  After re-reading this correspondence 
I think that the best way to proceed is to adopt Herman's suggested 
rewording (with slight changes) for the RDFS semantic conditions.

The amended text reads as follows (beginning at the anchor 
http://www.w3.org/TR/rdf-mt/#defDinterp and proceeding for 4 
paragraphs past the table. The text has been changed to properly 
organize the references to 'first condition', 'second condition' and 
so on, but the substance has not been changed.)

----------
If D is a datatype map, a D-interpretation of a vocabulary V is any 
rdfs-interpretation I of V union {aaa :<aaa,x> in D} which satisfies 
the following extra conditions for every pair <aaa, x> in D:

General semantic conditions for datatypes.
<table>
<firstrow>

I(aaa) = x and I satisfies the triples

aaa rdf:type rdfs:Datatype .
aaa rdfs:subClassOf rdfs:Literal .

</firstrow>
<secondrow>

if "sss"^^ddd is in V and <aaa, I(ddd)> in D and sss is in the 
lexical space of I(ddd) then:

IL("sss"^^ddd) = L2V(x)(sss);
IL("sss"^^ddd) is in LV;
IEXT(I(rdf:type)) contains <IL("sss"^^ddd), ddd>

</secondrow>
<thirdrow>

if "sss"^^ddd is in V and <aaa, I(ddd)> in D and sss is not in the 
lexical space of I(ddd) then:

IL("sss"^^ddd) is not in LV;
IEXT(I(rdf:type)) does not contain<IL("sss"^^ddd), ddd>

</thirdrow>
</table>

The first condition ensures that I interprets the URI reference 
according to the datatype map provided. Note that this does not 
prevent other URI references from also denoting the same datatype.

The second condition ensures that typed literals in the vocabulary 
respect the datatype lexical-to-value mapping. For example, if I is 
an XSD-interpretation then I("15"^^xsd:decimal) must be the number 
fifteen. The third condition requires that an ill-typed literal, 
where the literal string is not in the lexical space of the datatype, 
not denote any literal value. Intuitively, such a name does not 
denote any value, but in order to avoid the semantic complexities 
which arise from empty names, the semantics requires such a typed 
literal to denote an 'arbitrary' non-literal value. Thus for example, 
if I is an XSD-interpretation, then all that can be concluded about 
I("arthur"^^xsd:decimal) is that it is not in LV, i.e. not in 
ICEXT(I(rdfs:Literal)). An ill-typed literal does not in itself 
constitute an inconsistency, but a graph which entails that an 
ill-typed literal has rdf:type rdfs:Literal, or that an ill-typed XML 
literal has rdf:type rdf:XMLLiteral, would be inconsistent.

Note that the second and third conditions apply only to datatypes in 
the range of D. Typed literals whose type is not in the datatype map 
of the interpretation are treated as before, i.e. as denoting some 
unknown thing. These conditions does not require that the URI 
reference in the typed literal be the same as the associated URI 
reference of the datatype; this allows semantic extensions which can 
express identity conditions on URI references to draw appropriate 
conclusions.

The first condition also ensures that the class rdfs:Datatype 
contains the datatypes used in any satisfying D-interpretation. 
Notice that this is a necessary, but not a sufficient, condition; it 
allows the class I(rdfs:Datatype) to contain other datatypes.

------

If this is considered acceptable to everyone, I propose to make this 
change.  I will in any case undertake to produce a corrected version 
of the text, with anchors etc. in place.

Pat

PS to Herman: I am not so optimistic as you are about proving a 
version of the entailment lemma for D-entailment. The issue here has 
always been that datatypes are inherently idiosyncratic. For example, 
xsd:boolean has only 2 items in its value space, so for example the 
following is a valid XSD-entailment:

a p "true"^^xsd:boolean .
a p "false"^^xsd:boolean .
b type xsd:boolean .
|-
a p b .

but I despair of writing a general set of rules which would be 
sensitive to all possible value-space cardinality conditions. 
Similarly, there are many valid XSD entailments arising from ordering 
constraints on particular value spaces; and of course who knows what 
entailments might arise from yet-to-be-defined datatypes? The real 
issue here is that the L2V(d)(x) constraint is really arbitrarily 
powerful, even to the point of going beyond first-order (ie R.E.) 
expressivity; and it is up to the particular datatype how much of 
that power it chooses to wield: so I do not think that we can 
possibly prove a general completeness lemma for datatype entailment.

Pat


-- 
---------------------------------------------------------------------
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
phayes@ihmc.us       http://www.ihmc.us/users/phayes