From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>

Date: Tue, 02 Sep 2003 15:46:57 -0400 (EDT)

Message-Id: <20030902.154657.68539772.pfps@research.bell-labs.com>

To: phayes@ihmc.us

Cc: www-rdf-comments@w3.org

Date: Tue, 02 Sep 2003 15:46:57 -0400 (EDT)

Message-Id: <20030902.154657.68539772.pfps@research.bell-labs.com>

To: phayes@ihmc.us

Cc: www-rdf-comments@w3.org

From: pat hayes <phayes@ihmc.us> Subject: Re: issues with the 5 Sept version of RDF Semantics Date: Mon, 1 Sep 2003 18:56:46 -0700 [...] > >Appendix B: > > > >The definition of subinterpretation is flawed. Saying that > >subinterpretation is defined in terms of triples, or even single-element > >graphs, is different from defining subinterpretations in terms of graphs. > >I suggest dropping the incorrect phrase that talks about triples. > > I fail to follow your point here. What is the flaw, and what is > incorrect? Bear in mind that all this refers only to simple > interpretations and that a graph amounts to a conjunction. It is not the case that the condition before the "i.e." in the following quote is equivalent to the condition after the "i.e.". I view this as a flaw. Given two interpretations I and J, say that I is a subinterpretation of J and write I << J when J satisfies every triple that I satisfies, i.e. if I satisfies G then J satisfies G, for any G. [...] > >The proof of the Herbrand Lemma is not correct. In the proof there is the > >claim that ``if I satisfies E then I makes true all the triples that > >Herb(E) makes true'', but this claim has not been shown. > > I would have thought it was obvious by inspection. Not at all. Herb(E) makes true many graphs that are not subgraphs of E. The whole point of this lemma, I thought, was to show that this doesn't matter. > Herb(E) maps the > vocabulary to itself, and I maps the vocabulary to IR-I, and then the > conditions for being a projection are just the satisfaction > conditions on E. I have rephrased the wording of the proof slightly: > it now simply observes that the interpretation mapping is a > projection mapping: the result then follows from the immediately > preceding discussion in the text. I view the proof as being circular and no proof at all. [...] > >Translation to LBase: > > > >Even the new version of LBase is inadequate as a target for a mapping from > >RDF. It leaves open several fundamental issues including the nature of > >character strings. Further, the inclusion of single quotes in LBase > >strings is not possible > > Sure it is. Just include them; the result may be awkward to parse > mechanically, but it is in fact unambiguous. ''' denotes the string > consisting of a single single quote, ''ab'c' denotes the string > 'ab'c, etc. . Not at all. Consider ((?v1 = ''') and (?v1 = ''')) How is this to be parsed? [...] > >, so there is no way of translating RDF literals > >that contain single quotes. > > > >Several aspects of the translation to LBase continue to be problematic. > >There is no firm definition of NatNumber in LBase, so, for example, it > >might be the case that rdf:Property(rdf-member(001)) > > OK, suppose that is correct (it will be if you consider '001' to be a > numeral: I have no axe to grind on that issue). That is an axiom in > Lbase, note. > > >, leading to problems > >with URI references like rdf:_001. > > I have phrased the translation rule more carefully so that it refers > to RDF container membership property names (not simply URI refs) of > the form rdf:_nnn I don't see any change in this area. > > The treatment of XML structures is > >inadequate. XML structures can have language tags, which, by itself, may > >not be a problem, but is an indication that insufficient care has been > >taken in the definition of XML structures. > > That may well be true; the Lbase note did not go deeply into XML > issues. The primary goal of Lbase is to align the logical semantics > of different SWELs. > > >There is no attempt to show that > >all URIs can be used as names. > > ? Lbase names can be any unicode strings. Huh? Can ``(and'' be an Lbase name? I don't think that every unicode string can be an Lbase name. > Are there any URIs which > are not renderable as unicode strings? No, but that is not the point. [...] > >In addition to the above problems, the translation to LBase continues to be > >incomplete. For example, there is no axiom that makes all classes be > >subclasses of rdfs:Resource. > > Ah, you are right. I had not noticed that, indeed: I need to add this > explicitly now that subClass is not extensional. > > Now fixed. > > Your use here of 'continues' suggests that you have noticed this > earlier; I do not recall you mentioning it, however. If you are aware > of any other omissions or errors in the translation I would be > grateful to be told about them all at once rather than one at a time. I have at many times pointed out problems with the translation to Lbase, including incompletenesses in various parts of the translation, starting with a message I sent to you on 19 December 2002. Every time I have looked over the translation to Lbase I have have discovered problems; every problem I have discovered I have pointed out immediately. > Pat I am now very unmotivated to continue trying to make the RDF specifications workable. Why should I bother to even try when this is the treatment I get? Peter F. Patel-SchneiderReceived on Tuesday, 2 September 2003 15:50:38 UTC

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