Re: issues with the 5 Sept version of RDF Semantics

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

Received on Tuesday, 2 September 2003 15:50:38 UTC