Re: issues with the 5 Sept version of RDF Semantics

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>

```
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.
>
> >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

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