Re: Problem with auto-generated fragment IDs for graph names

On Feb 16, 2013, at 5:30 AM, William Waites wrote:

> On Fri, 15 Feb 2013 16:17:17 -0600, Pat Hayes <phayes@ihmc.us> said:
> 
>> Not quite. In a sane world, the name of the graph would always
>> denote the graph, be it an IRI or a bnode. But the WG has
>> decided that IRIs can be used to label a graph while at the same
>> time denoting something else, eg you can use an IRI denoting a
>> person to be the graph label of a record pertaining to that
>> person (or an IRI denoting a time to label a graph true at that
>> time, etc..).
> 
> It seems we are back to the two incompatible uses of graph:
> 
>    - For making statements about statements
>    - For partitioning triples arbitrarily
> 

Well, I don't know about "back". This issue has never gone away, we just decided to abandon it. 

> The obvious next question is, suppose we go back and do allow blank
> nodes to refer to graphs as seems to make sense, and we end up with a
> bunch of statements, and a bunch of statements about those (supposing
> only two levels deep for now), how do we then partition those into
> groups for administrative or provenance or whatever purposes?
> 
> Pretty soon we also wonder why on earth we have a "default" graph that
> is special. Sure it makes sense as a configuration option for a query

> answering engine to have some sort of default to help compose queries
> more succinctly, but surely that's a surface detail.

Well, the whole idea of datasets was invented by SPARQL for use by SPARQL, so we can at least give that a nod in passing. 

> Graphs that are
> written down without labels in trig are just graphs without names. And
> why can't we refer to this graph without a name and that graph without
> a name?

Because you need a way to refer to it, which tends to be something like a name. 

> 
> So, having got rid of the anomaly that means we can't refer to graphs
> in the usual way, and excised the special status of the "default"
> graph because we can now refer to any number of graphs, we need
> another level of indirection to express things like, "I heard from
> Alice that Bob thinks the moon is made of green cheese",

Once you can do one level deep, and you have graphs at both ends, you can weave as many layers of indirection as you like. 

> 
>    { :bob :thinks { :moon :substance :cheese;
>                           :colour :green } } :source :alice.
> 
> Or written out in longhand,
> 
>    _:b0 {
>        _:b1 :source :alice.
>    }
>    _:b1 {
>        :bob :thinks _:b2.
>    }
>    _:b2 {
>        :moon :substance :cheese.
>        :moon :colour :green.
>    }
> 
> And we could even add,
> 
>    _:bX {
>        <statements_by_alice> :includes _:b0
>    }
> 
> somewhere to effectively include the whole tree in the partition that
> we have made for things that Alice has said that may be otherwise
> unrelated.

I'd like to see the RDFS ontology for :includes, but yes, in principle. 

> 
> But I think that somehow trees are controversial. The whole idea of
> making the graph label not refer to the graph so as to make partitions
> was to avoid trees and nesting.

? Not in my recollection. The main (only?) reason was because the IRI might already refer to something else, eg a person or a time.

> 
> If we wanted to make the design even simpler, we could just ditch the
> idea of a graph altogether and give each statement an identifier. Then
> the whole thing could be easily and consistently built up from that,
> 
>    :g1 a :Graph;
>        :hasStatement :s1, :s2, :s3...
> 
> But the WG has been over this ground before, hasn't it?

I don't recall seeing that last idea before. 

But for the record, I wasnt intending to open up all this stuff. All I want is to have a semantics which supports the one-graph-has-triples-which-refer-to-another-graph case. This seems very useful, and providing it to users, if we can do that easily (and I now think we can), seems like a no-brainer. It doesn't have to be the default graph that does the referring, by the way, but that seems to be the case that people want.

Pat


> 
> -w

------------------------------------------------------------
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 Saturday, 16 February 2013 16:51:59 UTC