Re: Comments on RDF Concepts and Abstract Data Model

From: pat hayes <phayes@ai.uwf.edu>
Subject: Re: Comments on RDF Concepts and Abstract Data Model
Date: Wed, 20 Nov 2002 13:14:27 -0600

> >From: Jeremy Carroll <jjc@hpl.hp.com>
> >Subject: Re: Comments on RDF Concepts and Abstract Data Model
> >Date: Mon, 18 Nov 2002 15:59:12 +0100
> >
> >>
> >>  Hi Peter
> >>
> >>  I am responding to some of your comment
> >>
> >>  http://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0053.html
> >>
> >>  in particular:
> >>
> >>  [[
> >>  Major comment:
> >>
> >>  The RDF graph is syntax.  As such it makes no sense to define a notion
> >>  of equality over literals, which are pieces of syntax.
> 
> Peter, why do you say it makes no sense? It makes perfect sense to 
> me. If syntax is character strings, then equality is defined by 
> string equality; if it is some other kind of structure, then equality 
> is defined by other means. But it is still meaningful.

Sure, it is possible to produce an equality relationship on syntax, and one
can do so without producing contradictions, but what has one achieved?  I
claim that less-than-nothing has been achieved, as the equality on syntax
does not correspond to any meaningful relationship, and, worse, can easily
lead to confusion on the part of users, who will unknowingly think that
this notion of equality has some useful meaning.

> >  It is just as
> >>  if one wanted to defined equality in C by defining it over pieces of a
> >>  C program.  Similarly, it makes no sense to define equality of nodes
> >>  or triples.
> 
> Again, it makes sense. It may be irrelevant or beside the point, but 
> it is not incoherent.

Precisely.  It can be done, but it is irrelevant, beside the point, and
confusing and thus does not make sense.

> >  > ]]
> >>
> >>  The new version
> >>  http://www.w3.org/TR/2002/WD-rdf-concepts-20021108/
> >>
> >>  continues to define equality over literals.
> >>
> >>  I believe this is helpful and do not intend to change it, but am open to
> >>  further discussion.
> >>
> >>  The uses that the WG has found for such notions are:
> >>
> >>  + in the test cases
> >>    Without a defined notion of equality between literals, we would not have a
> >>  defined notion of equality between graphs, which is necessary for the test
> >>  cases.
> >
> >First, the new test cases working draft (of 20021112) does not even contain
> >the string 'equal', so I don't see how a notion of equality helps in the
> >test cases. 
> >
> >Second, I note that the test cases working draft does, however, talk about
> >graph isomorphism.  I maintain that this notion is a *much* better notion
> >for use here, particularly as it cannot be abused by developers and users
> >to give cover to illegal uses of syntactic (un-)similarity as semantic
> >(un-)similarity.
> 
> Ah, that would be an incorrect reading. But the solution is to put in 
> guard prose to warn users not to misinterpret.

I maintain that it would be better not to use ``equality'' at all, as no
matter how much guard prose is included some users will misinterpret.

> >>  + in the semantics. Without clarity about the nature of the syntactic
> >>  objects that the semantics are defined over, it seems difficult to know what
> >>  the semantics may be about.
> >
> >The semantics is defined on syntactic structures sure, so it needs to know
> >what these syntactic structures are.  However, there is generally no need
> >to know whether two syntactic structures are identical - instead all that
> >is needed is the mapping from syntactic structures to semantic meaning.
> 
> You have to get the notion of syntactic identity clear first before 
> it even makes sense to talk about mappings. You essentially made this 
> point yourself when you argued for talking in terms of isomorphism. 
> Exact syntactic identity is often quite a complex matter to state 
> these days, what with distinctions like glyphs versus characters and 
> the impossibility of canonical character orderings in some Unicode 
> layers and so on.
> 
> >
> >>  Your example of a C program is uncompelling
> >>  because it is usually taken as unproblematic what the underlying syntactic
> >>  objects are. All programming languages have to decide whether they are case
> >>  sensitive or not, which is the sort of level at which I perceive the literal
> >>  equality rules.
> >
> >Not so, programming languages have to provide a mapping from their syntax
> >to their semantics (however this is couched).
> 
> First they have to say what their syntax actually *is*.
> 
> >  If, for example, a
> >programming language had case-insensitive *strings*, then the only notion of
> >string equality it would support should be this case-insensitive one - any
> >notion of comparing the surface syntax of strings would be meaningless for
> >this language.  Similarly, RDF should not define a notion of equality
> >(which has strong semantic connotations
> 
> Its just an English word. You are making a fuss about a matter of 
> writing style.

Perhaps, but given that there has been a lot of discussion over just how to
handle the meaning of datatype literals would it not be better to remove a
potential source of misunderstanding.

> >) over its syntactic structures,
> >particularly if this notion is not the same as semantic identity.  If RDF
> >needs some notion of identity for its syntactic structures, then this
> >notion should be referred to by some other word, such as isomorphism.
> 
> For me, 'isomorphism' has unfortunate connotations. I realise it is 
> mathematically accurate; but if we took that seriously and tried to 
> conduct this discussion in strict mathematical terms, it would 
> rapidly become impossibly unmanageable. Ive tried it. For example, 
> syntactic categories like 'identifier' very quickly become 
> equivalence classes under isomorphisms. But what kind of entities are 
> the members of those equivalence classes? They are not the members of 
> the original classes. One has to ascend (descend?) into 
> category-theoretic language in order to keep ones head straight. If 
> we start telling our audience that in order to understand what an RDF 
> graph is they have first to read Birkhoff & Mclain, forget it.
> 
> Pat

I don't think that one has to go this far, just stay away from terms that
can give rise to misunderstanding.  If you want, you could talk about the
same program or the same triple.

peter

Received on Thursday, 21 November 2002 05:52:24 UTC