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

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 begin to wonder (sorry Sandro) whether the concept of a g-text is really useful here at all...


> 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:-)

> 
>> 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...:-(

> 
>> 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...

Ivan



> 
> Cheers,
> 
> Nathan
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf