W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2001

Re: Active issue rdfms-graph; formal description of properties ofan RDF graph

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 23 Oct 2001 17:25:55 -0500
Message-Id: <p0510104ab7fb9d7df4f5@[]>
To: Dan Connolly <connolly@w3.org>
Cc: w3c-rdfcore-wg@w3.org
>[It seems that folks have taken the lack of a reply
>from me as agreement; not so...]
>Pat Hayes wrote:
>>  >I suggest, again, the following simple abstract syntax:
>>  >
>>  >   An RDF graph is a set of triples <S, P, O>; each
>>  >   of S, P, O is a term; a term is either an absolute
>>  >   URI reference, a bNode, or a literal.
>>  >   --
>>  >http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0140.html
>>  >
>>  Well, I'm happy to go along with the more liberal labelling rules, to
>>  be sure. These restrictions only make life more complicated by the
>>  need to avoid exceptional cases in the model theory, closure rules,
>>  etc.. (One of the reasons why I laid out all those conditions on N
>>  and E labels was to make it easy to erase them one at a time :-)
>>  But this abstract syntax is really just N-triples,
>It's very close to N-triples... that is: N-triples is designed
>to closely model this abstract syntax, yes...
>>  and I prefer to
>>  keep the graph as a separate entity.
>This sort of graph is separate. N-triples syntax is a BNF sort
>of thing: the statements are ordered; there's whitespace
>and punctuation, etc. bNodes have a particular
>syntactic representation, etc. In the graph formalism
>I'm suggesting, the only thing we specify about
>bNodes is that they're different from absolute
>URI references and literals.
>>  >The model theory straightfowardly applies to this liberal
>>  >syntax, I believe. Regarding scope, I think it's straightforward
>>  >to treat bNodes the way local variables are treated in
>>  >traditional logical syntax: you rename them as necessary
>>  >when you merge graphs.
>>  Yes, it CAN be done that way. I think its uglier, and also it is kind
>>  of cheating, since right now we don't have anything in RDF syntax
>>  (not even in Ntriples) to specify the 'document' boundary. And
>>  remember how much trouble we had with this at the F2F?
>Yes, we do have something in RDF synatax and in n-triples
>to specify the document boundary: the document boundary

There is no syntactic marker of the boundary, which is the point. How 
do we define the merge of two documents?

>We don't have a way of putting two scopes
>into one document, but that's by design
>(or: by design limitation, as one of our issues suggests).
>And no, I don't remember how much trouble we had with
>this at the F2F; I wasn't there the 2nd day. The
>previous model theory, which was based on n-triples
>concrete syntax, worked just fine for me.

The MT works fine, but the issues of how to handle anonymous 
resources gave us incredible trouble. Maybe they shouldnt have done, 
but they did.

>Let me review the record of the 2nd day...
>It seems to come down to this:
>   Pat: the realization that I have, if I do the MT as attached
>   to the graph, then issues like scope of exist quant
>   go away becauset there are no scopes in the graph.
>   --
>If you substitute "set of triples..." as above
>for graph, the epiphany holds, no?

NO!! That's the point. The merge of two graphs is a meaningful graph, 
and the union of two sets of triples is a set of triples. But the 
document consisting of that set of triples doesnt correspond to the 
graph got by merging the graphs. The only way to describe the proper 
'merge' of two triples-documents requires us to talk explicitly of 
renaming, standardizing apart, generating names, etc. etc. ; its a 
mess. A familiar mess, but a mess nonetheless. We found a way to get 
out of the mess. Its worth being a little careful with a few 
definitions to stay out of the mess.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 23 October 2001 18:26:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:05 UTC