Re: RDF-ISSUE-120 (set-of-triples-are-graphs): Is any set of RDF triples an RDF graph? [RDF Concepts]

On Mar 14, 2013, at 10:41 AM, Antoine Zimmermann wrote:

> Le 14/03/2013 15:54, Peter F. Patel-Schneider a écrit :
>> I'm confused here.
>> 
>> What do you see to indicate that a particular set of triples cannot form
>> an RDF graph?
> 
> Pat saying it repeatledly. Last time was yesterday:
> 
> "An RDF graph is a set of triples **such that every bnode in the set is in a single bscope** (that is the second axiom), and we can then say that the graph is in the bscope."

Strictly speaking, that does not limit how sets of triples can form graphs, since you can define "scope" to be vacuous. But in any case, your own thinking (see below) requires that not every  set of triples is a graph. 

> In http://lists.w3.org/Archives/Public/public-rdf-wg/2013Mar/0125.html
> 
> 
>> I assume that you are talking about issues of bnode scope.  However, I
>> don't see anything in the discussion of bnode scope that prevents any
>> particular set of triples from being an RDF graph. As far as I can tell,
>> bnode scope could be completely removed from Semantics without changing
>> anything.
> 
> So why does bnode scope even appear in Semantics if it has no impact?
> What is it trying to solve?

Honestly, Antoine, if you really do not know this by now, I despair of how to explain it to you.

>> Yes, there is a change in the semantics. Previously the merge of RDF
>> graphs involved changing bnodes as necessary. This is no longer the
>> case, which does change how RDF works, but this change is being made to
>> conform to practice.
> 
> In what way it align better with practice than before. In practice, bnodes are identified somehow, and the merge operation requires that nodes identifiers be "standardised apart" before uniting the graphs into one. This requirement would ne necessary, whether scopes are put in the abstract syntax or not.

The current 2004 merge requires that bnodes *themselves* are standardized apart. What this change will do is eliminate this issue from the abstract syntax level and keep it at the surface syntax level, which is where it belongs (and as you say, will still be necessary just as before.) RIght now we have TWO standarizations apart going on: the 'surface' version using bnodeIDs and the 'deep' one invovling actual identity of bnodes. Which is crazy, and wierdly complicated, and is a bug in the conceptual model.

> This is not bringing a solution to an existing problem, and it's certainly not repairing something broken.

What is broken, currently, is that merging requires that blank nodes *themselves* are standardized apart. Not their bnodeIDs, but the *actual nodes*. This does not make operational sense, because there is no way even detect identity of blank nodes. If you like, you can see all this talk of scopes as a way to make clear what the identity criteria actually are for blank nodes, in terms of the identifiers used to mention them and the syntactic scopes of those identifiers. 

> What applications need is a way to determine whether some triples have to be considered as forming one graph, as opposed to forming several graphs.

But you say, earlier, that every set of triples is a graph. On this view, then, If I have several graphs, then the set of all the triples in them IS a graph, whether I "consider" it to be one or not. In fact, on this simple account, "considering" doesn't come into the issue at all. If the entire universe contains N triples, then there just *are* 2|N graphs, as a Platonic fact about sets. What anyone "considers" anything to "be" is irrelevant. 

It seems clear that (just like everyone else) you don't really think that every set of triples is a graph. So which sets are graphs? It sounds like only the ones that someone wants to "consider" as a graph, should be a graph, but that seem awfully vague.

> E.g., I have 2 NTriples files. Should I consider that they serialise two halves of a graph, or that they serialise two graphs?

They are both, if graphs are simply sets of triples. 

> The application has to decide, but it shouldn't be the business of semantics to tell them how they do this.

And semantics does not tell them how to do it. But what this scope language does is to provide a way to state this choice, in exact terms. I agree that this decision has to be made. It is exactly the decision whether these sets of triples are in two scopes or both in one scope. 

I think you are actually thinking in scope terms when you talk about graphs here. But the 'graph' language, with the 2004 definitions backing it up, just does not do the job you (we all) want it to do. Suppose I say I want to "consider" those two documents to be serializing two graphs. Still, their set-theoretic union does exist (according to Zermelo-Fraenkel set theory, and indeed every other set theory) so that union graph also exists. So what does it mean to say that I am not "considering" it to be a graph? Neither Semantics nor Concepts says anything much about "considering". And similarly, if I want to consider them as subgraphs of this larger graph: well, OK, but a subgraph is still a graph, so why would that make any difference to these smaller graphs being graphs? Again, the scope language cuts through silly questions like this and makes the answer clear. 

> Once the decision of partitioning the triples into graphs (or in one graph for that matter) the semantics of 2004 applies straightforwardly.

What about the situation where I have two graphs which I am not, um, considering to be parts of a larger graph, but they happen to share a blank node. Does that make sense? I would say no, but the 2004 specs do not rule it out. 

> BTW, I would like to be able to put a single graph in multiple N-Triples files, because I want to be able to send huge RDF graphs in multiple packets.  So I would not be happy if the spec says that the scope is necessarily delimited by the file.

Well, that is an issue you should take up (immediately!) with the authors of the spec that defines N-Triples. Is it legal to split a graph over multiple files? If so, we need to revisit the question of just what does define the scope in this case. How would you signal the boundaries of the graph, if it is split over multiple files? If two huge graphs are split up in this way and I get a whole pile of these files, how do I know which files are part of which graph? (Put anoher way, how do I know which scope each triple is in?)

Pat

> 
> 
> AZ.
> 
>> 
>> peter
>> 
>> On 03/14/2013 02:39 AM, RDF Working Group Issue Tracker wrote:
>>> RDF-ISSUE-120 (set-of-triples-are-graphs): Is any set of RDF triples
>>> an RDF graph? [RDF Concepts]
>>> 
>>> http://www.w3.org/2011/rdf-wg/track/issues/120
>>> 
>>> Raised by: Antoine Zimmermann
>>> On product: RDF Concepts
>>> 
>>> All work on RDF until early 2013 have been made under the assumption
>>> that a set of RDF triples is an RDF Graph (and vice versa). Recent
>>> discussions on bnode scope suggest that there are combinations of RDF
>>> triples that do not form a graph. Precisely, the idea is that only the
>>> triples that belong to the same "scope" (whatever that means) can be
>>> in the same RDF graph.
>>> 
>>> This also impact the definition of an RDF triple, as there can be two
>>> blank nodes in the same triple.
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> -- 
> Antoine Zimmermann
> ISCOD / LSTI - Institut Henri Fayol
> École Nationale Supérieure des Mines de Saint-Étienne
> 158 cours Fauriel
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 42 66 03
> Fax:+33(0)4 77 42 66 66
> http://zimmer.aprilfoolsreview.com/
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 15 March 2013 04:11:07 UTC