RE: Comments on the new RDF Test Cases draft

>Replying to both Jan's and Pat's in one email.
>There were essentially two points expressed in [1],
>all coming from the fact that probably the test cases draft has been 
>underestimated,
>as it touches an extremely important issue like conformance to RDF.
>The two points can be so summarized:
>a) lack of formalization
>b) problem of what is the correct notion of conformance
>
>On a), once raised the point (and noted that even, according to the standard
>definition, the previous statement was not only inaccurate, but even 
>incorrect),
>there's not much to say. Whatever we decide as per b), it has to be 
>formalized,
>unless we want to go back to the errors made with the previous RDF (....).
>
>[incidental note: this comes from the fact that despite "graph" is of common
>use for RDF, the only formalization of RDF graph is the one 
>currently in the MT,
>which is not what we meant here, and that certainly necessitates of 
>a formalization
>of the concept of isomorphism

Graphs are sets (of triples). Use set-identity as isomorphism, that 
should do.  I will write up an appendix for the final version of the 
MT giving exact definitions, including blank-node isomorphisms.

>. This is related to the "rectangles and ovals" point
>raised in [2].]
>
>[second incidental note on formalization attempts: please be careful 
>to formalize
>really everything, it's easy not to be complete...]
>
>Then, onto b), which is the real core of the issue.
>The "easy fix", apparently, is just to define a classic isomorphism 
>on rdf graphs
>"as we mean it", i.e., up to blank node renaming (like Pat and Ian suggests,

To repeat: this is NOT what I suggested. I have tried to make it as 
clear as I possibly can that there is no such thing as 'blank node 
renaming', since blank nodes do not have names that can be re-named. 
The phrase is meaningless and oxymoronic. As far as I can see, the 
definitions of RDF graph syntax in the MT document are precise and 
reasonably accurate, modulo the error already noted.  (To fess up: it 
is true that the definitions given do not give a formal articulation 
of the distinction between type and token for graph syntax, and also 
do not make clear the intended relationship between blank node 
identity and parsing RDF/XML, both omissions which should be 
rectified in a final version.)

>  and as
>it was already in the intention of the original Test Cases text).
>But there's a deeper issue here, and it is whether it is in fact 
>more appropriate
>or not to define conformance as semantical equivalence (cf. [1] and [3]).
>Like Pat realizes in [4]:
><quote>
>The trouble with using semantic criteria in the syntax is that you
>have to specify WHICH semantics you are using. Does it have to be
>simply equivalent, rdf-equivalent, or rdfs-equivalent?
></quote>
>and that's, yes, one of the parts I was hinting at when raising the 
>issue in [1], cf
><quote>
>There are possible related issues of conformance here, but that's the
>only major error (or issue, depending... ;) I could find.
></quote>

Seems to me that kinds of entailment, on the one hand, and levels of 
conformance, on the other, are different issues which are more 
orthogonal than identical. One could have different levels of 
syntactic conformance, after all. I would suggest that the normal 
relationship between conformance and entailment would be that each 
vocabulary (namespace) simply be considered to have its appropriate 
semantics, so that if someone uses say rdfs:subClassOf then they are 
presumed to be using it with its meaning defined by rdfs 
interpretations. The use of prefixes like rdf- and rdfs- in the MT 
document is intended to express this convention.

>So bare-bones, suppose an RDF parser digests one of the test cases, 
>and produces
>all the triples we expect to (as per the "minimal interpretation" currently
>understood in the Test Cases), plus the following triple:
>[rdf:type] [rdf:type] [rdf:Property] .
>Is it compliant to RDF, or not?

I would say yes, though (1) you might not want to call it simply a 
'parser' since it apparently can also do some rdf inferences, and (2) 
it would also be a compliant parser if it did not.

>The set of triples that have been produced are virtually indistinguishable
>according to the Model Theory (which is the *meaning* of a graph, 
>independently
>of its syntax).

They are obviously syntactically distinguishable, but they rdf-entail 
each other (they are rdf-equivalent). That seems perfectly clear: do 
you see a problem with this?

>So, if we limit ourselves to the current Test Cases interpretation, we are
>relying on the syntactical structure rather than on the semantical one

Of course we are. Inference is defined over syntactic forms, of 
necessity. Whether the inference is correct or not is a semantical 
question, but the actual test cases *consist* of syntax. I don't find 
this either inelegant or broken.

>,
>which is something I find very unelegant, and to some extent even 
>logically broken.
>Said this, yes, this is opinionable and no one (included me) will scream loud
>if the "syntactical equivalence" is used rather than the semantical one.

What are the two notions of equivalence that you are talking about 
here? Is your point that the test cases should be stated in terms of 
entailment? But many of them *are* stated in this way, so what is 
your point?

>However, I do think it's more elegant to go the semantic way, and can't really
>see many advantages to go for the syntactic way.
>
>Now, if (if) the semantical way is the chosen one, there's the further issue
>of what semantical equivalence are we talking about: RDF or RDFS.
>But this is part of another big issue (a la [1]) that depends on 
>whether we go syntactic
>or semantics, so there's no point in expand this email any further now ;)
>
>Syntactic or semantics?

Both, surely.

Pat

>-M
>
>[1] http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0081.html
>[2] http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0077.html
>[3] http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0083.html
>[4] http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0094.html

Received on Wednesday, 22 May 2002 12:42:17 UTC