Re: [GRAPHS] g-box - abstraction or concrete?

Ivan Herman wrote:
> On Feb 28, 2011, at 13:25 , Nathan wrote:
> [snip]
>>> I went back to Pat's email that started this discussion (thanks Pat:-). And I went back to Sandro's mail for the terminology (thanks Sandro:-). It did look simple at the time:-); We have these notions
>>> 1. Abstract RDF graph, ie, a mathematical abstraction as a set of triples (per Pat), a.k.a. a g-snap (per Sandro's terminology). It is an abstract thing like a number (as opposed to a numeral)
>>> 2. (Concrete) RDF graph a.k.a. graph token (per Pat), a.k.a. a g-box (per Sandro's terminology), that, when poked, return a textual representation (a.k.a. serialization a.k.a. g-text) of an abstract graph. g-boxes may have a URI. Blank nodes are bound to a specific g-box. (Are g-boxes non-informational resources if they have a URI? I guess...)
>>> There is no time in all this. Well, no temporal logic, because, of course, you poke a box at a particular time but, say, if you poke my personal (non-informational resource) URI, the system will provide a foaf file today that is different than the one yesterday. But the community could live with that without temporal logic, why couldn't it tomorrow?
>> I agree, although I took Pat's graph-token to mean g-text and not g-box, and take "concrete rdf graph" to mean g-text as well, different to the concept of g-box.
> 
> Yes, we do seem to have a different notion. A graph in a triple store (look at the way SPARQL looks at things) is a g-box for me. It is not serialized, so it is not a g-text, but it definitely may have a URI...

I agree though, lol. I believe Sandro and Pat are correct when they say 
there is an abstract set of triples (g-snap) and a realization of those 
triples (g-text), and I believe you and Sandro are correct when you say 
a g-box exists, and I agree with (Pierre?) that g-boxes are abstract and 
that we deal with realizations of them, and thus conclude that there 
must be four concepts - that isn't to say the four must be mentioned in 
RDF that is, just that they must be identified and considered during 
this process.

The distinction between is that we have boxes (think named graph where 
the value changes over time) and sets of triples (don't change state), 
and both of those things can be split in to abstractions and 
realizations. Previously we had the term "RDF Graph" to refer to a set 
of triples, both the abstract mathematical set and the realization of 
it. And in the community the same was true for "Named Graphs" (boxes).

Question is, which ones do we need to mention? My contention is that if 
we are to have trig like named graphs, where a single name can refer to 
two different quoted graphs over time, then we need the concept of "box" 
in there (remaining silent on state though), and that quoted graphs do 
not require the concept of "box". We definitely need the concept of a 
"graph", unsure whether we need to recognize both the abstraction 
(g-snap) and the realization (g-text) though, certainly the g-text I 
would have thought, since we only really deal with g-texts generally.

If you agree, at least in principal that there are four distinct 
concepts here, then I can write up that wiki page to describe them all 
for our reference (and to clear an action). Noting that the presence on 
the wiki page doesn't indicate we need to fully or partially handle them 
  in the specs. Thus, let me know when we're clear :)

> I begin to wonder (sorry Sandro) whether the concept of a g-text is really useful here at all...

imho, yes definitely, both g-snap and g-text are def needed, and will 
simplify the specs considerably without changing the semantics - as Pat 
said at the top of this thread.

>> And further, I take the notion of g-box to be an information resource (something for which you can get a realization (copy/instance) of it's current state, a representation, a g-text) - which is a major difference in our thinking, one I'd like to iron out, perhaps off-list.
> 
> Maybe so. At this moment, I am not sure it makes a big difference. g-box: something concrete, g-snap: something abstract. That is it.
> 
> [snip]
>>> Interestingly, after going a great round, we may end up by the same things... Because, at the end of the day, we may have two different notions that we want to formalize and/or give syntax to:
>>> 1. A syntax for an abstract graph, much like we use the "1"^^xsd:integer for the mathematical abstraction of the number 1. This is what {<a> <b> <c>.} is in TriG or N3
>> by that definition, if "1"^^xsd:integer is a literal, then so must be {<a> <b> <c>.} !?
> 
> It is something similar, I agree. For reasons below, I would prefer not to call and consider it a literal. A pseudo-literal:-)

that's fine be me, as I'm sure you know I care less about what we call 
the thing, and more about being able to use it in the future :)

>>> 2. The notion of a URI given to an RDF graph (RDF graph token for Pat, g-box for Sandro). We may or may not provide a specific syntax for that
>> as earlier, graph-token = snapshot-realization = g-text from what I can tell, fundamentally different to g-box, which is the critical distinction I'm trying to get across here, one is naming something which can have different values/representations over time, the other is not.
> 
> And this distinction does not resonate to me I am afraid...:-(

would a call help, private or group (first tf call re graphs?) I believe 
it's pretty critical that we all come to a unified understanding of 
these concepts before moving on, it'll make life much easier moving 
forwards afaict - get our story straight.

>>> As a side issue (but I think it is important): it is true that, in a very general sense, it is attractive to talk about Graph Literals. However, literals have a very specific sense and role in the RDF semantics, as well as in the OWL semantics, it has the separate notion of D-entailment in RDFS, even more datatype reasoning in OWL, the current RDF has restriction as for the usage of literals in subject position, etc. If we talk about graph literals, I am afraid we would open up Pandora's box. As a specific issue, if we allow for graph literals in subject position but then we would have to look at the general issue of literals-as-subject in general and that has already created a formidable turmoil on the mailing list. Let us not go there. I would therefore suggest _not_ to talk about graph literals but a very specific thing (that we may have to add to the RDF document separately). We can call it quoted graph, g-snap-realization, whatever...
>> so we could never "{<a> <b> <c>.}"^^x:graph ? - although yes, quoted-graph is fine by me and matches what I'm thinking. The literal part is just whether the thing is a literal or not (which I'd say it is, and as per your definition 1. above).
> 
> ... and I would prefer to keep Pandora's box closed...

okay, I certainly won't hard-line on names, there's always data URIs and 
other ways around such things for bc / compat.

Cheers,

Nathan

Received on Monday, 28 February 2011 17:21:39 UTC