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

Graham,

Thanks for this.  The intention of this action was to review the changes to 
semantics Pat has made in response to pfps-04 -05 -06 -07 -08 -10 for 
whether they were ok from an RDF point of view.  The intent being to ensure 
that the WG were comfortable that these changes accurately reflected the 
WG's  intent.

There's a lot of comment here.  Is this basically a thumbs up or thumbs 
down?  If down, what are the substative issues we need to discuss before 
disposing of these?

Brian

At 17:26 02/04/2003 +0100, Graham Klyne wrote:

>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 12:04:43 UTC