>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