- From: pat hayes <phayes@ai.uwf.edu>
- Date: Mon, 14 Apr 2003 22:09:15 -0500
- To: w3c-rdfcore-wg@w3.org
- Message-Id: <p05111b00bac11ff92d89@[10.0.100.12]>
Responses to Graham below, in-line. These refer to the version dated
14 April (same uriref) These are all either 'done' or 'now moot' or
'disagree', except the ones marked @@ which still require some action
from me or some discussion.
>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
>...
Im going to keep 'isomorphic' since equivalent means logical
equivalence in the MT. Isomorphic graphs are logically equivalent, of
course :-)
@@But I may be able to manage without this definition at all, in
which case I'll just scrub it. Will check tomorrow.
>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.
>]]
done
>...
>
>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.
>]]
Would it, in fact? Even if literal values are resources and have
urirefs, there would still be a syntactic distinction between the
uriref and the literal itself. Eg numerals aren't urirefs, right?
>
>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.
This has been aired, as you know, and Im sticking by my guns.
>...
>
>Section 1.5 [Nit]
>
>Isn't Skolemization named after one Thoralf Skolem? As such should it not
>be capitalized, like Boolean?
Done
>...
>
>Section 2, inference rules for instance lemma
>
>Short form: I don't think you have, as claimed, an *inference rule* for
>the instance lemma.
No, really, it is an inference rule.
>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.
right, it does.
>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 conc
>would be such an inferelusion of which the premiss is an instance
>(i.e. *replacement* of a triple by its instance).
Well, inference rules don't replace; they add.
>
>Also, you say there is no inference rule corresponding to the subgraph
>lemma. I would have thought that:
>
> G1 union G2 |- G1
>nce rule.
But it applies to entire graphs, not to triples. Ive added a phrase
by way of explanation.
> 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.
Ive rewritten all this stuff now using a Jeremiacal phrase throughout.
>...
>...
>
>Section 3.1, defining IP?
>
>....
>I think the text has the first and second conditions switched around.
Right. Fixed.
>
>...
>
>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 ?
@@Ah, a VERY good point. Yes, it should. This needs a fairly big edit
of this whole section which I will try to get done tomorrow. Also I
will have to re-draw the second figure (again !!)
>...
>
>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,
>]]
All done.
>...
>
>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.
Good point. Done, its now in a little section 3.3.1. all on its own
> Also, for the corresponding closure
>rules noted in section 4.2.
Ive left that since its informative and hardly worth putting
separately. The back reference is now clearer, however.
>
>Also, the comment about not including a picture seems somewhat redundant.
Removed.
>...
>
>Section 3.4: [Nit]
Section 3.4 has been rewritten. I think it is now much tighter and
harder to misunderstand.
....
>
>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.
@@We need to get this right. My understanding of the situation is this.
1. lang tags are syntactically legal in typed literals (though I have
no idea why, it seems like a bloody silly decision for non-XML typed
literals)
2. Apart from the XML case, they are ignored by the semantics and the
datatyping. So while the tag might be present in the literal, it is
ignored and is NOT part of the lexical space of the datatype.
>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,
yes
>but ill-formed,
no, it just has some redundant information in it
>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)
It would if the pair was understood to be the thing in the lexical
space, but it isn't.
>
>[[
>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?
The issue is whether sss is in the space. The ttt is deliberately ignored.
>
>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.
I agree, we need to have a consistent story about this. There is no
doubt it is a mess whichever way we do it.
FWIW, seems to me that by trying to keep the syntax a wee bit simpler
we have made everything else a lot more complicated. I would like to
see lang tags purged from typed literals altogether, they seem to
play no useful role, even in XML (since you can always include them
in the actual XML document-character string, right?).
>
>The outcome might also impact section 4.3
>
>...
>
>Section 3.4, confused by wording
>
....
Much of this is moot, now 3.4 is rewritten.
>...
>
>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.
>]]
text rewritten
>...
>
>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 .
Done. The [ ] notation is now purged.
>...
>
>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.
>]]
Done
>...
>
>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?
Yes, I will reword that. I need to rewrite that prose somewhat to
cover the stuff that Herman introduced, in any case. @@Not done yet,
but soon.....
>
>...
>
>Section 4.3, a "small semantic extension"?
>
I decided to just scrub this, its more confusing than helpful.
Entire paragraph deleted.
Thanks for comments and detailed reading.
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@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu for spam
Received on Monday, 14 April 2003 23:09:18 UTC