ACTION 2003-03-14#6: comments on semantics doc

Per ACTION 2003-03-14#6, reviewing:
   http://www.coginst.uwf.edu/~phayes/RDF_Semantics_Editors.html

I've done a general read-through, with particular attention to the red text.

...

Section 0.3 [Nit]

Defines "isomorphic" graphs, but elsewhere [1] we agreed to talk of 
"equivalent" graphs.

[1] http://www.w3.org/2001/sw/RDFCore/20030123-issues/#danc-01
     http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0602.html

...

Section 1.3 [Nit]

[[
2. A distinguished subset IP of IR., called the set of properties.
]]

might be more consistent (cf. item 1 in same list) to say:

[[
2. A distinguished subset IP of IR, called the set of properties of I.
]]

...

Section 1.3

I mentioned the other day that it had been proposed in another place (IETF 
URI BOF) to define resource as something identified by a URI -- no URI then 
no resource.  This would be at odds with:

[[
However, this does not imply that literals should be identified with urirefs.
]]

I don't suggest any change at this time, since that's only a suggestion for 
a revised version of RFC 2396, but mention it as it could become a future 
point of confusion or dissent.

...

Section 1.5 [Nit]

Isn't Skolemization named after one Thoralf Skolem?  As such should it not 
be capitalized, like Boolean?

...

Section 2, inference rules for instance lemma

Short form:  I don't think you have, as claimed, an *inference rule* for 
the instance lemma.

Discussion:  When you talk of inference rules, I am expecting to see a 
complete syntactically based chain that gets from some premiss to a valid 
conclusion.

As given, the closure rules show how one can create new graphs that are 
entailed by some initial graph by addition of triples, but I don't see how 
to use them to create an conclusion of which the premiss is an instance 
(i.e. *replacement* of a triple by its instance).

Also, you say there is no inference rule corresponding to the subgraph 
lemma.  I would have thought that:

    G1 union G2 |- G1

would be such an inference rule.  I guess you mean there is no closure rule 
corresponding to the subgraph lemma?

...

Section 3.1

Notes about canonical form terminology;  I would ask Jeremy to confirm the 
appropriate form of words for this.  Current wording in Concepts suggests:

[[
if x is a *Canonical XML* document then
<x, I(rdf:XMLLiteral)> is in IEXT(I(rdf:type)) and x is in LV
]]

and

[[
IL("xxx"^^rdf:XMLLiteral) is the *canonical form* of the XML document xxx.
]]

...

Section 3.1, defining IP?

[[
The first condition could be regarded as defining IP to be the set of 
resources in the universe of the interpretation which have the value 
I(rdf:Property) of the property I(rdf:type).  The second condition forces 
every rdf interpretation to interpret rdf:type as a property, which will be 
used to associate 'type' values with resources.
]]

The first condition is:
   IP contains I(rdf:type)

The second condition is:
   x is in IP if and only if <x, I(rdf:Property)> is in IEXT(I(rdf:type))

I think the text has the first and second conditions switched around.

...

Section 3.1, rdf:first, rdf:rest

Would it not be appropriate to specify semantic conditions that IP contains 
I(rdf:first), etc?

Also, rdf:subject, rdf:predicate, rdf:object, rdf:_1, rdf:_2, ... , rdf:value ?

...

Section 3.2.2 [Nit]

[[
In general, this amounts to knowing the type of a container, and having a 
partial 'list' of the items in the container.
]]

The use of the term 'list' here may be unfortunate (cf. RDF collections), 
so maybe say?:

[[
In general, this amounts to knowing the type of a container, and having a 
partial enumeration of the items in the container.
]]

Also?:

[[
RDF does not support any entailments which could arise from *enumerating* 
the elements of an rdf:Bag in a different order. For example,
]]

...

Section 3.3, [Nits]

I am wondering if the discussion of semantic extensions that strengthen the 
domain and range semantic conditions might usefully be offset from the main 
text in some way, as an explanatory NOTE or suchlike, since it's not 
central to understanding RDF as is.  Also, for the corresponding closure 
rules noted in section 4.2.

Also, the comment about not including a picture seems somewhat redundant.

...

Section 3.4: [Nit]

[[
Formally, a datatype d is assumed to be defined by four items:
]]

I'm not sure if this means something different from:
[[
Formally, a datatype d is defined by four items:
]]

...

Section 3.4 [Nit]

[[
The set of recognized datatypes always includes the built-in datatype 
rdf:XMLLiteral and may include the XML Schema, part 2 built-in datatypes 
defined in [XML-SCHEMA2], referred to here as XSD.
]]

I think that some of these built-in datatypes are not really suitable for 
use with RDF, such as IDREF and QName.  Suggest:

[[
The set of recognized datatypes always includes the built-in datatype 
rdf:XMLLiteral and may include some of the XML Schema, part 2 built-in 
datatypes defined in [XML-SCHEMA2], referred to here as XSD.
]]

...

Section 3.4, datatypes:

[[
ICEXT(I(rdfs:Datatype)) is a subset of D
]]

I can't see, from the descriptions given, how a datatype may be in D but 
not a member of ICEXT(I(rdfs:Datatype)).

...

Section 3.4, datatypes and consistency with Concepts

I think we currently have an inconsistency:
[[
For any typed literal "sss"^^ddd in G and string ttt, I("sss"^^ddd) = 
I("sss"@ttt^^ddd)
]]

where Concepts says that literals of types other than rdf:XMLLiteral have 
lexical spaces that consisting of just strings, so the case quoted above 
just should not arise.
   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Datatypes
   (4th para)

Hmmm... but see also:
   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Graph-Literal
   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Literal-Equality
   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Literal-Value

The last of these suggests that a typed literal with a language tag is 
syntactically OK, but ill-formed, in which case (according to my reading of 
the semantics) it should have a value which is not in LV;  i.e. not the 
same as I("sss"^^ddd)

[[
For any typed literal "sss"^^ddd in G, if I(ddd) is in D and sss is not in 
the lexical space of I(ddd) then IL("sss"^^ddd) is not in LV
]]
In voew of the above, there seems to be a gap in the formal 
conditions.  What about "sss"@ttt^^ddd, where "sss"@ttt is not in the 
lexical space of ddd?

Before putting this topic to bed, I think we need an agreed resolution for 
danc02:
   http://www.w3.org/2001/sw/RDFCore/20030123-issues/#danc-02
slightly expanded to address language tags as well as datatypes.

Then this might be fixed in Concepts or semantics or both.

The outcome might also impact section 4.3

...

Section 3.4, confused by wording

I had some trouble figuring how this:
[[
The sixth condition says that the meaning of any typed literal which uses a 
recognized datatype is the value of the literal character string under that 
datatype.
]]
was saying the same thing as:
[[
For any typed literal "sss"^^ddd in G, if I(ddd) is in D and sss is in the 
lexical space of I(ddd) then IL("sss"^^ddd) = L2V(I(ddd))(sss)
]]

Maybe say something like this?:
[[
The sixth condition says that the meaning of any typed literal which uses a 
recognized datatype is the value of the datatype's lexical-to-value mapping 
applied to the literal character string.
]]

...

Section 3.4, XML datatypes

[[
These semantic conditions are exactly similar to the above if one defines 
the lexical space of rdf:XMLLiteral as the set of all XML documents and all 
pairs of XML documents and language tags, and @@add link to concepts here@@ 
L2V(I(rdf:XMLLiteral)) as defined in [RDF Concepts].
]]

Currently, I think the link you want would be to:
   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#dfn-rdf-XMLLiteral

...

Section 4.1, XML literal closure rule

[[
xxx aaa mmm .

where mmm is a well-formed XML typed literal with the same @@canonical form 
as lll.
]]

Based on the current Concepts document, I think you want something like:

[[[
where mmm is a well-formed XML typed literal, whose language tag is the 
same as lll, and whose string component is the canonical form of the string 
component of lll.
]]]

(but please check with Jeremy)

...

Section 4.1, Nit

[[
Note, the rules rdf2 and rdf3, and the semantic conditions to which they 
correspond, apply only to typed literals which contain the exact RDF 
identifier of the built-in datatype.
]]

Might be clearer as:

[[
Note, the rules rdf2 and rdf3, and the semantic conditions to which they 
correspond, apply only to typed literals that contain the exact URI of the 
built-in XML datatype.
]]

...

Section 4.2

[[
xxx aaa "sss"[@ttt] .
]]

I note that there's a new bit of notation slipped in here.  I think the 
intent is reasonably clear, but it might be more correct to list rules for

   xxx aaa "sss" .
and
   xxx aaa "sss"@ttt .

...

Section 4.2, *the* types?

[[
For example, the range and domain assertions in the RDFS axiomatic triples, 
together with the rules rdfs2 and 3, establish the rdf:type values of much 
of the RDFS vocabulary.
]]

A resource may have multiple types.  I would suggest dropping *the*, as in:

[[
For example, the range and domain assertions in the RDFS axiomatic triples, 
together with the rules rdfs2 and 3, establish rdf:type values for much of 
the RDFS vocabulary.
]]

...

Section 4.2, *every* xxx in v?

[[
The rules will generate all assertions of the form

xxx rdf:type rdfs:Resource .

for every xxx in V, and of the form
]]

Surely, the closure rules generate these assertions for all xxx used 
(directly or indirectly) in the graph whose closure is computed?

(Taking V as the vocabulary of the interpretation used, which by my 
understanding may be larger than that used by a graph to which it is applied.)

Similarly, for every class name?

...

Section 4.3, a "small semantic extension"?

[[
It may be useful to incorporate the assumption that any uriref appearing in 
a typed literal is presumed to be a datatype, which would be captured by 
the following rule. Note however that this is not strictly valid, so 
represents a (small) semantic extension.
rdfD -1

aaa ppp "sss"[@ttt]^^ddd .

ddd rdf:type rdfs:Datatype .

Datatype clashes and violations may be considered to be error conditions. 
However, such graphs are not strictly ill-formed, and can be used to 
support valid RDFS entailments which might be meaningful in certain contexts.
]]

I'm not sure what it means to be a "small semantic extension", but the 
above seems quite significant to me.  According to section 3.4 and the 
first semantic rule in that section, all members of I(rdfs:Datatype) must 
be recognized datatypes.  (I'm still not usre if I(rdfs:Datatype) *is* the 
set of recognized datatypes; see comment above).  Thus, I think the "small 
semantic extension" noted above would require *all* datatypes used in a 
graph to be recognized datatypes, which I suppose would mean that any graph 
that used an unrecognized datatype would automatically be false under such 
interpreation.

...

Appendices only given cursory skim... no comments noted.

...

#g



-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Wednesday, 2 April 2003 11:50:10 UTC