W3C home > Mailing lists > Public > www-rdf-comments@w3.org > July to September 2003

Re: review of July 15 draft of RDF Semantics document

From: pat hayes <phayes@ihmc.us>
Date: Tue, 29 Jul 2003 02:31:46 -0500
Message-Id: <p06001a18bb45de65f265@[]>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: www-rdf-comments@w3.org

>  >
>>  The change list is not part of the document. Please review the document.
>I strongly differ.  I was told by Brian McBride, in various messages to me
>also sent to www-rdf-comments@w3.org, that
>is suitable for review, so I did review it.  This document includes a
>section headed ``Change List since Last Call''.  How can this prominent
>section not be part of the document?

Because it is a change list? We must understand 
English differently. If you prefer, please delete 
the grey box labelled 'change list ' and review 
what remains.

>  >
>>  >
>>  >Drastic Problem:
>>  >
>>  >There has been a significant conceptual change to simple interpretations.
>>  >IP is not required to be a subset of IR.  This does not appear to be in
>>  >response to any comment to the RDF Core Working Group nor to be in response
>>  >to any problem with the RDF model theory.  This change may have
>>  >consequences for other formalisms, including OWL, but no announcement about
>>  >it has been made.
>>  >
>>  I would not describe this as a significant conceptual change, so much
>>  a small technical improvement to the mathematical machinery. It was
>>  mentioned in an informative email which you received and replied to.
>I take it that you are referring to this exchange:


>** Subject: Re: possible semantic tweak
>** From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
>** To: phayes@ai.uwf.edu
>** Cc: horrocks@cs.man.ac.uk
>** Date: Wed, 04 Jun 2003 06:52:36 -0400 (EDT)
>** X-Mailer: Mew version 2.2 on Emacs 21.1 / Mule 5.0 (SAKAKI)
>** From: pat hayes <phayes@ai.uwf.edu>
>** Subject: possible semantic tweak
>** Date: Mon, 2 Jun 2003 19:02:38 -0500
>** > Guys, some (very) recent work on the SCL project has suggested a
>** > possible semantic modification which may be relevant to the RDF/OWL


>** >
>** > My question to you is, SUPPOSE that I were to tweak the RDF MT so as
>** > to allow this; would that possibly simplify the OWL-DL correspondence
>** > theorem? Because as far as I can see it would make no difference at
>** > all to the RDFS documents: the difference between this and the
>** > current MT is invisible in RDFS, as far as I can tell. So if you
>** > think this would be worth doing, let me know (off-list) and I will do
>** > it editorially.
>** >
>** > Pat
>** I don't see that it would make the correspondence theorem significantly
>** simpler.  There already is a similar feature in the RDFS model
>** theory for OWL, and it was very easy to set up. 
>** Further, I am very skeptical that you would get any mileage out of this
>** trick in RDF.  Remember that most elements of the RDF and RDFS vocabulary
>** are subjects or objects of some triple in RDFS models (either rdfs:domain,
>** rdfs:range, rdfs:subClassOf, or rdfs:subPropertyOf) and thus would have to
>** belong to IR. 
>** peter
>I don't view this exchange as an announcement or even an indication that
>the change will be made nor do I view my response as either an endorsement
>of the change or an indication that the change would not cause any problems
>for OWL.

I did not say that it was an announcement. And I 
did not ask for, or expect to get, an 
*endorsement*. I asked you if the change, which I 
described as editorial and indicated that I was 
planning to make, would be of help in the OWL 
layering. Ian, the other editor, reacted 
positively. Your reaction, though negative to my 
request, did not indicate that you found the 
change likely to cause problems.

>>  It was not made capriciously; it reflects a recent observation that
>>  this slight weakening of the basic (not RDF) graph model theory makes
>>  'layering' of the sort requested by Jeff Pan and others somewhat
>>  easier to achieve, since the basic model theory now allows a
>  > conventional first-order structure of an interpretation of a graph
>>  which satisfies the conventional syntactic layering: that is, if a
>  > URIref occurs in a graph only in predicate position, it is no longer
>>  required to denote something in the universe of quantification.  This
>>  allows the basic model theory to be more conventional, since it no
>>  longer requires the use of non-well-founded structures in all cases.
>>  The credit for this idea is due to Chris Menzel, and it arose as
>>  consequence of the SCL project working to eliminate the 'Horrocks
>>  sentences' which had different satisfiability conditions in SCL and
>>  FOL; this is of course closely related to the RDF/OWL layering
>>  issues. Using a similar device, SCL has now achieved full FOL
>>  compatibility.
>>  This does not change any RDF or RDFS entailments or semantic
>>  conditions, since these require that IP and IR overlap on the parts
>>  of the RDF and RDFS vocabularies to which semantic conditions apply,
>>  as the text notes; and since it weakens rather than strengthens the
>>  conditions on simple interpretations, I do not believe that it will
>>  have any significant effects on OWL.  Other members of the Webont
>>  working group had reacted favorably to this change.  If you feel that
>>  there are any problems arising from this change, please say what they
>>  are.
>The point is that I don't see that there are no problems resulting from
>this change.  This determination could require considerable effort.

Allow me to suggest a way to determine this.  Do 
the OWL specs at any point refer to or rely on 
the structure of simple interpretations which are 
not RDF interpretations?  If not, there is 
nothing further to discuss. If so, do the specs 
at that point rely in any way on IP being a 
subset of IR in such non-RDF simple 
interpretations? I do not believe this is the 
case, although I concede that there may be parts 
of your proof of the correspondence theorem that 
I have not checked in sufficient detail.

>>  >Problem:
>>  >
>>  >The definition of a proper instance admits a switch of blank nodes in the
>>  >graph, e.g., replacing _:a with _:b and vice versa, as a proper instance,
>>  >but this shouldn't be a proper instance.
>>  It isn't a proper instance according the definition given:
>>  "A proper instance of a graph is an instance in which a blank node is
>>  mapped to a name or to some other blank node in the graph, so that in
>>  the instance a blank node has been replaced by a name or two blank
>>  nodes in the graph have been identified. "
>>  On re-reading this I see that the comma may be 
>>misleading, and have deleted it.
>Removing the comma changes the meaning of a proper instance.

Not in the way I read the English, but OK, the change has been made.


>>  >There are other problems in the definition of the merge as well.
>>  I am unable to respond to that.
>The definition needs to be rewritten.  I have had to read the defining
>sentence numerous times to figure out just what is going on, often with
>different results, and I'm still not sure that there isn't some problem in
>the definition.

I have rewritten the definition to be hopefully more coherent.

>  > >Problem:
>>  >
>>  >In Section 1.3 a vocabulary is defined as a ``set of URIrefs''.
>>  It is not defined there; the text refers to such a set as being a
>>  vocabulary, which is correct. However it could be better worded: I
>>  have changed this to "set of names".
>OK, Section 1.3 only defines the notion of a vocabulary of an
>interpretation.  However,
>	All interpretations will be relative to a set of URIrefs, called
>	the vocabulary of the interpretation, ...
>defines the vocabulary of an interpretation to be a set of URIrefs, not a
>set of names.

Right; as I say, I have changed that.

>>  >However, in the change log and in Section 0.3, a vocabulary is supposed to
>>  >be able to contain typed literals.
>>  A set of URIs without typed literals is a vocabulary, however.
>Agreed, but I don't see the point you are trying to make here.
>>  >Problem:
>>  >
>>  >There is no definition of a ``literal character string'' or a ``language
>>  >tag'', used in the definition of simple interpretations.
>>    "literal character string"  changed to  "character string".
>  >
>>  Language tag is used in the sense of RFC3066. I have inserted a
>  > reference link to the concepts document
>>  which should clarify the intended meaning.
>Is this consistent with RDF Concepts?  I should think that you should
>instead defer to this other document.

The link is to that document.

>>  >Problem:
>>  >
>>  >The conditions for denotations should be augmented with more conditions
>>  >like ``if I(p) is in IP''.    I suggest adding as well ``if s, p, and o are
>>  >in V''.
>>  Why do you feel this is necessary? This wording has not changed in
>>  many versions of the document.
>Well, you have the one condition, why include if you don't include the others?

Because it isn't necessary. But....

>>  But since you insist, I have added the condition explicitly.
>>  >Problem:
>>  >
>>  >The example in Section 1.4 is incomplete in that it does not define LV.
>>  True; it is only an example. LV can be any suitable set.
>The example should say this.

OK, done.

>>  >Also, IL is necessarily the empty map as there are no typed literals in the
>>  >vocabulary of the example.
>>  Ah, point taken. I have added "plus all typed literals with one of
>>  these as the type URI"
>>  >  This makes the fourth triple false, not true.
>>  >
>>  >The ``oddity'' of having a typed literal denote a non literal is not ruled
>>  >out in datatyped interpretations.
>>  That isn't what was meant by 'oddity', but I have deleted this comment.
>>  >
>>  >The explanation of why triples involving plain literals are false is
>>  >incomplete, as plain literals do not have to denote character strings.
>>  Changed to "containing a plain literal."
>I don't think that this does the trick.  The point is that plain literals
>include those with language tags, which do not denote strings.

Right. Since they are self-denoting (with or 
without language tags) and there are none in the 
universe, all those triples will be false for 
lack of a denotation.

>>  >Silliness:
>>  >
>>  >rdf-interpretations do not just ``impose extra semantic conditions on crdfV
>>  >and typed literals with the type rdf:XMLLiteral''.  Why not just say that
>>  >rdf-interpretations impose extra semantic conditions?
>>  Because this draws attention to the fact that they do not impose any
>>  extra conditions on the rest of the RDF vocabulary.
>Well, sort of, but I consider the use of crdfV misleading.

Im afraid I disagree.

>It is true that there are rdf-interpretations that do not impose conditions
>on (the denotation of) rdf:subject.  However, any rdf-interpretation that
>includes rdf:subject in its vocabulary does impose conditions on (the
>denotation of) rdf:subject.

Only those which arise from its being a simple 
interpretation. The text uses the word "extra 
semantic conditions" to indicate this distinction.

>Further, not all rdf-interpretations impose
>conditions on every typed literal with the type rdf:XMLLiteral, as not all
>such literals need be in the vocabulary of the interpretation.
>So I suggest some different wording here.

The text does not say *all* typed literals. I 
think the intended meaning is sufficiently clear 
from the context, since all interpretations, of 
any kind, can impose conditions only on the 
vocabulary of the interpretation. The sentence is 
only intended to be an introductory remark, the 
actual conditions in the formal definition are 
quite precise.

>  > >Problem:
>>  >
>>  >The document states several times that it is agnostic as to whether XML
>>  >literals are strings.
>>  The document  refers to XML values, ie 
>>whatever it is that XML literals denote.
>>  >However, the claimed completeness of the RDF entailment
>>  >rules means that XML literals are not strings.
>>  The strings in the actual XML literals themselves are strings, as
>>  clearly stated several times in this and other RDF documents.
>  > Whether or not an XML literal denotes a string is where the
>>  agnosticism comes in.  I am not sure which of these you mean here.
>[From a separate email exchange, with new comments
>** Subject: Re: pfps-04
>** From: pat hayes <phayes@ihmc.us>
>** To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
>** Date: Wed, 23 Jul 2003 21:55:41 -0500
>** >From: pat hayes <phayes@ihmc.us>
>** >Subject: Re: pfps-04
>** >Date: Wed, 23 Jul 2003 14:56:07 -0500
>** >>  >There is still a mismatch between the RDF Entailment Rules, which, if
>** >>  >complete, determine that XML Literals are not the same as strings
>** >>
>** >>  ?? How can they possible determine that? Please explain.
>** >>
>** >>  Pat
>** >
>** >[The following assumes that certain aspects 
>of the RDF model theory will be
>** >fixed up appropriately.]
>** >
>** >Let x be any well-typed XML literal string.  Then "xx"^^rdf:XMLLiteral,
>** >where xx is the appropriate encoding of x, 
>has the same denotation in every
>** >interpretation of a vocabulary that includes "xx"^^rdf:XMLLiteral, namely
>** >the canonical XML object corresponding to x.
>** That assumes that 'canonical XML object' is uniquely welldefined. I
>** don't think it is, as I have observed differences of opinion about
>** what exactly it is. So I don't accept that it does have the same
>** denotation in every interpretation. It denotes whatever someone
>** thinks the specs mean. Opinions seem to differ.
>If this is not well defined, then it would not be possible to create an RDF
>datatype for XML Literals, as RDF datatypes require a well-defined mapping
>from lexical to value spaces.

No. If the phrase is not welldefined then there 
will be alternative possible interpretations of 
it. For example, one might identify XML objects 
with character strings; another might not. Both 
possibilities are welldefined in the mathematical 
sense,  of course, but people might legitimately 
disagree about which of them is 'correct', given 
the English text of the various specifications. 
In the meanwhile, the RDF model theory is capable 
of treating either or both of them as possible 

If we - that is, the various WGs - can come to a 
clear determination of this issue then I would be 
happy to state the result in the document. In the 
meantime, however, the only options are to be 
silent on the topic, which I think is not helpful 
to the reader, since some readers will read it 
one way and others read it another; or to be open 
and explicit about the agnosticism being assumed, 
to make it clear that the model theory as stated 
works with either interpretation, which is what I 
tried to do.

In fact, I have removed the 'agnosticism' text 
from the latest draft, but I note that the issue 
seems to still be unresolved. If it stays 
unresolved, then I plan to put the statement of 
explicit agnosticism back into the document, 
possibly with some explanatory text to clarify 
what it means and the reason for stating it.

>** >Let this object be x'.
>** >
>** >If x' is a string
>** Nobody said it was a string.  x is a string in a XML literal, ie a
>** syntactic entity.  x' is an XML Literal value, something in an
>** interpretation.  Whether or not those are strings is left open: as
>** far as the MT is concerned, they might not be, ie there are
>** satisfying interpretations where they are not.
>** Pat
>Note that the above says that ``*If* x' is a string''.  This does not mean
>that x' has to be a string.  However if x' is a string (of Unicode
>characters), then
>[Taken from my first response to Pat.]
>* If x' is a string then 
>*	ex:a ex:p x^^rdf:XMLLiteral .
>* rdf-entails
>*	ex:a ex:p "xx'" .
>* where xx' is the n-triple encoding of x'.
>* Therefore for the RDF entailment rules to be complete, no XML Literal can
>* have a character string as its denotation.

No, look. That *entailment* holds only if it can 
be shown to follow in *every* interpretation. My 
point, in interjecting that x' might not be a 
string, was (and still is) precisely that this 
question remains unresolved: so there can be 
interpretations satisfying the conditions, as far 
as we know, in which x' is not a string.  If it 
is a string, then indeed *in that interpretation* 
your argument goes through: but one cannot 
justify a conclusion of entailment by considering 
only a subset of the possible interpretations.

>  > >Problem:
>>  >
>  > >The treatment of quoted strings in LBase is so bad that I can't even begin
>  > >to figure it out.  However, it is definitely the case that the translation
>>  >to LBase changes the denotation of character strings.
>>  Indeed there was an error in the table at this point, left over from
>>  an earlier edit, my apologies.  I also see, on checking, that the
>>  character-escaping convention in the published Lbase note is not in
>>  fact the version I was following when writing the appendix. No wonder
>>  you were unable to follow it.
>>  Let me suggest that I simply ignore all the character-escaping
>>  complexities and insert a remark in the text as follows:
>>  "Note, these translation rules ignore issues of character escaping in
>>  encoding character strings in literals: an implementation based on
>>  these rules might need to use more care with strings containing the
>>  characters ' and \."
>>  The mapping now simply puts single quote marks around the literal
>>  string, with no attempts at character escaping.
>>  I have made these changes.
>>  Bear in mind that, as the text states, this translation is provided
>>  only as an informative alternative for readers who prefer this style.
>>  The Lbase document emphasizes that Lbase is not intended as an
>>  implementation language or for direct use as a SWEL.
>As you know, I am unhappy with the presence of this appendex in the
>document.  This new issue only increases my unhappiness.

Well, to be brutally frank, your *happiness* is 
not really at issue here. If you would like us to 
start trading mutual unhappinesses I am willing 
to do so, but I fear the results might be rather 
sordid and not conducive to making progress on 
the various technical issues that we have to try 
to get completed.

>  > I have also weakened the claim in the 5th 
>paragraph of section 0.1 to read :
>>  "The translation technique offers some advantages and may be more
>  > readable, so is described here as a convenience. The axiomatic
>>  semantic description differs slightly from the normative model theory
>>  in the body of the text, as noted in the appendix."
>Does this mean that the claims of ``same semantic theory'' and ``exact
>correspondence'' are gone?   If so, what then remains?

What the text states: it is non-normative and 
provided as a convenience for some readers. Like 
it or not, many people do prefer this style of 
reading a semantic specification. I am confident 
that anyone who does prefer it would be capable 
of making it exact enough for their purposes.

>  > >Whether this causes
>>  >problems I cannot determine.
>>  >Problem:
>>  >
>>  >The translation to LBase seems to assume in some places that LBase uses
>>  >URIrefs of some sort, e.g., the expansion of Lbase:String.  However, the
>>  >LBase document itself uses non-URIref names for these things, e.g., String.
>>  Whoops. Sorry, indeed that is a mistake, arising from having too many
>>  versions of the document lying around.  The 'Lbase:' prefixes should
>>  not be there. Fixed.
>There are Lbase: prefixes in
>http://www.w3.org/TR/2003/NOTE-lbase-20030123/, which are at best a source
>of confusion.

I see that indeed they are used in the example 
given there. That is ugly, and I apologize for it 
and will contrive to have it corrected in an 
upgrade of the note; but as they are not used in 
the actual text, and the example is stated 
emphatically to only be an illustration, and the 
Semantics appendix is clearly a better example, I 
do not feel that this is a fatal problem.

>  > >Problem:
>>  >
>>  >The translation to LBase ignores some of the aspects of URI references, I
>>  >believe.  In particular, I believe that RDF URI references can include
>>  >whitespace, which is not allowed in LBase names.
>>  Really?? Well, I was unaware of that possibility, I confess. If true,
>>  that would require us to change the Lbase syntax to allow for this
>>  possibility. The intention was always that URIrefs could be used as
>>  Lbase identifiers.
>This needs to be investigated, I think.

I will undertake to investigate it and correct 
the Lbase note appropriately if required. The 
intention is that any URIref can be a Lbase 

>>  >  I note also that LBase
>>  >doesn't even bother to define character strings.
>  >
>>  What would count as a definition? The Lbase document refers to
>>  sequences of Unicode characters.
>I just did a search for ``character'' in
>http://www.w3.org/TR/2003/NOTE-lbase-20030123/, which is the document
>referred to by http://www.w3.org/sw/RDFCore/TR/WD-rdf-mt-20030117/, and did
>not find any definition of what a character string is.
>A definition would be something like
>	A character string is a finite, possibly empty sequence of Unicode
>	characters [ref].
>The point is that character strings are only defined for some notion of
>characters, and there are quite a few possibilities to choose from.

That document is not written to be a formal spec document.

>>  >Problem:
>>  >
>>  >The translation to LBase can be broken by use of suitable URI references in
>>  >the RDF graph.
>>  >  For example the translation of
>>  >
>>  >	ex:a rdf:type LBase:String .
>>  >
>>  >would imply the translation of
>>  >
>>  >	ex:a rdf:type rdfs:Literal .
>>  >
>>  >which is not a valid rdfs-entailment.
>>  The intention was that the Lbase special names cannot be generated
>>  from URIrefs.
>>  This is fixed now, see above, since the corrected special names are
>>  not legal URIs or Qnames.
>The document http://www.w3.org/TR/rdf-concepts/, referred to by
>http://www.w3.org/sw/RDFCore/TR/WD-rdf-mt-20030117/ as the definition of
>URIref, only requires that a URIref be a Unicode string that would produce
>a valid URI under a certain encoding. 
>This appears to allow for any sort of URI, including relative URIs, which
>could clash with the Lbase special names.

This entire issue was beneath the radar when the 
Lbase note was written. I do not consider it to 
be a matter worthy of discussion, since Lbase is 
not intended to be a language for processing by 
machines, and the note says explicitly that the 
exact syntax is not important. If any such 
syntactic accident should arise it can treated in 
an ad-hoc manner, eg by writing all URIrefs in 
one font and the special names in a different 

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
Received on Tuesday, 29 July 2003 03:31:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:21 UTC