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

At 18:05 02/04/2003 +0100, Brian McBride wrote:
>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.

Er, yes, but I have to read through to remind myself about the details I'm 
checking.  I thought I was checking for possible errors introduced by the 
changes.

>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?

It's a mixture.  There are some points that I think need to be considered, 
but I would be prepared to defer to Pat's judgement on the outcome.  Nits, 
of course, can be passed over.

#g
--

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

Received on Wednesday, 2 April 2003 15:56:32 UTC