Re: issues with the 5 Sept version of RDF Semantics

>Technical Issues with the RDF Semantics Document
>(version dated 5 September 2003)
>
>Introduction:
>
>How can there be ``two versions of the same semantic theory'' that ``differ
>slightly''?  Either they are the same or they are not.

They are not the same ("differ") but the differences are minor and 
easy to understand and if necessary to modify ("slightly").

>RDF interpretations:
>
>The definitions of well-typed XML literal (strings) and XML values should
>be tightened up.  In the definition ``XML value'' maps typed literals into
>values; but in the semantic conditions ``XML value'' maps character strings
>into values.  The definition is for ``well-typed XML literal string'', but
>``well-typed XML literal'' is used as well, without a definition.

Sigh. I do not think that anyone reading this is likely to 
misunderstand it. A well-typed literal is a literal with a literal 
string which is well-typed according to the datatype named by the 
datatype URIref. However, I have added a sentence to make this 
explicit.

>D-interpretations:
>
>It is rather misleading to state that the only inconsistencies in
>D-interpretations are ``datatype classes and assertions that ill-typed
>literals are of type rdfs:Literal''.  There are other, closely related,
>ways to produce inconsistency, such as  requiring "<br />^^rdf:XMLLiteral
>to belong to ICEXT(I(rdf:XMLLiteral)).

That is true, and I have modified the text to mention this case also.

>
>Datatype entailment rules:
>
>I do not believe that rule rdfd4 is valid.  I don't see how under the
>current semantic rules for rdfs:subClassOf that one can infer an
>rdfs:subClassOf relationship from just a subset relationship.

Others have made the same point.  I have removed the rule and amended 
the wording to read as follows:

Suppose that it is known that the value space of the datatype denoted 
by ddd is a subset of that of the datatype denoted by eee; then it 
would be possible to assert that
ddd rdfs:subClassOf eee .
but this would require an explicit assertion; the subclass 
relationship does not follow from the subset relation alone.

This change has been noted as a substantial change in the change log, 
and may be modified in the light of WG discussion.

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

>Subinterpretations do not need to be sub-structures.

The remark was intended to be a guide to intuition, but it is simpler 
to delete it than to explain it fully.

>To see this consider
>interpretations that differ only in having extra elements of their domain,
>i.e., domain elements that participate in no true triples.  These
>interpretations will subinterpretations of each other, but there will be no
>sub-structure relationship between them.

That is true, strictly. However in this case, there is a common 
substructure of both of them. The full statement of the condition 
here would first define ( << and >> ) as a similarity relation, then 
show it was an equivalence relation, then point out that any 
equivalence class has a member which is a substructure of all the 
other members of the class. But this would take too long and be aside 
from the main point of the appendix anyway.

>The paragraph about mappings between components of interpretations is
>confusing.  What is a projection mapping?  What properties does it have?

The word "projection" was intended to be defining, not restrictive. I 
have rephrased the wording to make this clearer.

>What is the structure of an interpretation that needs to be preserved?

The structure described in the remainder of the sentence, following the "i.e."

>   I
>suggest dropping ``projection'' and ``preserves all the structure ...'',
>and simply stating the requirement.

Done, in the interests of a quiet life.

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

>The proof of the RDF Entailment Lemma is rather sloppy.  It refers to
>``well-typed XML literal''

That term now has a definition in the text.

>
>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. . In order to parse some Lbase you would have to work 
back from both ends to locate the enclosing quote marks surrounding 
the strings.  But, as the Lbase note says explicitly, Lbase is not 
primarily intended for machine processing.

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

>  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. Are there any URIs which 
are not renderable as unicode strings?

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

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@ihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 1 September 2003 21:56:40 UTC