Re: datatypes and MT (#rdfms-graph)

>Pat Hayes wrote:
>[...]
>>  >I think that's what we're discussing. I'm suggesting this
>>  >as a definition of an RDF graph:
>>  >
>>  >         terms:
>>  >                 constants (URIs w/fragids)
>>  >                 string literals
>>  >                 bnodes (existentially quantified variables)
>>  >         statement:
>>  >                 term term term.
>>  >         formula:
>>  >                 statement*
>>
>>  But that clearly isn't a definition of a *graph*, right? Its  an
>>  N-triples -style lexical syntax for specifying graphs, at best, so we
>  > still need to settle all the tidiness questions.
>
>No, not at all. n-triples has punctuation around URIs, whitespace,
>etc.
>
>The * in statement* isn't really intended as a kleene-star;
>more like: set of statement. Perhaps with a small change
>of emphasis/style it will look more like a graph:
>
>	Node = symbol U string U bnode
>	Edge = Node x Node x Node
>	Graph = 2^Edge
>
>where symbol is the set of URIs w/fragids; string
>is the set of unicode character sequences; bnode is
>a set disjoint from those two sets, and 2^X
>is notation for "sets of X's".

OK, but you ought to distinguish the nodes from their labels. Blank 
nodes don't have labels, after all.

>
>>  So what this amounts
>>  to is: to allow literals in subject position (OK with me)
>
>quite...
>
>>  and as arc
>>  labels (OK I guess, but seems kind of silly, eg how would we do
>>  datatyping of those?)
>
>er... we don't. literals are all strings, and the
>IEXT of all literals is empty.
>
>OK, it's pretty much arbitrary whether you put the
>"no literals in the predicate position" constraint
>in the graph syntax or the model theory. But my intuition
>says that the graph syntax is going to be in a lot
>more people's faces, and exceptions there are going
>to look uglier. I could go either way, though,
>if I got my way on the rest of the issues.
>
>>  and also have nodeId-style labels on arcs, to
>>  quantify over properties.
>>
>>  Now, that last idea seems to me to basically break the graph syntax
>>  proposal; there really isn't any point in having a graph syntax if we
>>  have to include a labelling device to provide a lexical way of
>>  indicating identity, rather than relying on the graph structure
>>  itself. We might as well just give up on the F2F decision you cite
>>  above, and use Ntriples (suitably relaxed, as you suggest) as the
>>  primary syntax.  Don't get me wrong; I can live with that; I have no
>>  trouble with bound variables, and the MT can handle existential
>>  properties. But there is considerable social evidence that many
>>  people have a lot of trouble with it; and more to the point, I really
>>  think that it amounts to a reversal of the decision about making the
>>  graph primary.
>
>Er... well, I wasn't there when the decision was made, and
>I don't really see why it was made. It seems like a case
>of making something sufficiently fuzzy that nobody can
>disagree with it.

Its not fuzzy; the graph syntax is perfectly well-defined. The great 
utility of the graph syntax is that it eliminates the need for 
scoping existential variables, because the thing corresponding to an 
existential variable is a blank node, and every blank node is unique; 
the question of whether two blank nodes are the 'same' or 'different' 
is settled in the syntax itself. This, in the graph syntax there are 
no bound variables, or local names, or anything at all with a local 
scope. This makes the graph syntax much easier for many folk to 
understand, apparently, folk for who the notion of a local name 
causes a lot of mental grief (see the mailing archives for evidence, 
or recall the best part of a day used up at the F2F arguing over 
this); and it certainly makes the definitions of things like graph 
merging much easier to state, since one doesn't need to get into 
issues like renaming, standardizing names apart, etc. , etc. In fact 
you don't need to do *anything* to blank nodes in a merge. As soon as 
we have any kind of locally scoped names in the graph, this critical 
advantage of the graph syntax is lost; and then I think there would 
be no advantage to be gained from using the graph syntax, and we 
would be better advised to revert to a lexical syntax of some kind, 
like Ntriples.

>
>>  It certainly is a rejection, in effect, of the
>>  *reasons* why that decision was made, viz. to get rid of bound
>>  variables (local names, anonymous things that had names anyway,
>>  skolems, whatever you want to call them) from the primary syntax. .
>
>Get rid of bound variables? What version of the model
>theory was rid of bound variables?

Every version. There are no bound variables in the graph syntax.

>certainly
>not the version published 25 September 2001:
>
>"This effectively treats all unlabeled nodes as existentially
>         quantified in the RDF graph in which they occur."
>
>	-- http://www.w3.org/TR/2001/WD-rdf-mt-20010925/

It *treats* them as existentially quantified, in the sense that a 
faithful translation of the graph syntax back into logic would map 
blank nodes (or bNode IDs) into existentially bound variables; but 
there aren't any such variables in the graph itself, so questions 
about what it means for a name to be 'local' do not arise; issues of 
accidental clashes of local names don't arise; and issues of 
determining and recording scopes don't arise. All labels in every 
graph are global in scope (urirefs and literals) and what would be 
the 'local' names simply aren't there. Unlabeled nodes don't have 
labels, so they don't need a scope.

>I do think I'm missing the point.

Its really only a technical point about a syntactic style, but I 
think it is a useful feature of current RDF that it would be a pity 
to abandon without very good reasons. If we do abandon it, the MT and 
all the stuff on reasoning and entailment will suddenly get more 
complicated both to state and to implement.

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Wednesday, 14 November 2001 11:11:40 UTC