RE: A radical proposal. (was: Re: new names for g-box, g-snap)

* Markus Lanthaler <markus.lanthaler@gmx.net> [2012-08-20 11:39+0200]
> On Friday, August 17, 2012 6:21 PM, Pat Hayes wrote:
> 
> > Maybe we should look at how other contexts handle this issue. After
> > all, the contrast between a labile thing and its state is pretty
> > universal. Take a vanilla web page, for example, 
> > [...]
> > So web pages (in fact, all
> > information resources identifed by URIs; I would hazard a guess) are
> > all state-bearing entities rather than a bunch of stuff in one of their
> > states. But, as I say, other communities seem to take this in their
> > stride.

I think this is a proposal for the following term mapping:
  gsnap -> representation
  gbox -> resource
  g{resource|label|whatever} -> resource name

I'm don't think I see how this substantially changes the semantics. Would it be
  1 word substitution
  2 massaging of surrounding text to resonate better with the terms
  3 a new way to tilt your head and see the semantic web
?

For either of the first tow, I'd be happy happy to see semantics in terms of g* and then have a bake-off later on to decide what terms would be most useful (leaving on the table the g* terms which are delightfully unambiguous).
If it's #2, then there's a bit more cleanup and risk, but still managable IMO.
Pat said that his proposal involved substantial rewrites, so perhaps he envisions this as #3 above.


> I fully agree with this. Looking at it from a REST perspective basically all
> you can do is to exchange representations (the current state) of resources.
> As soon as you receive that representation it might already be outdated.

Sure, but in the end, we need maths which isolate the effect of an opperation on a dataset.
Let's look at what we can help and what we need to be compatible with or improve upon:

A typical SPARQL Update test takes an input state of (defaultGraph? namedGraph*) plus an update opperation and yields a final state.
For legacy reasons, these aren't compartmentalized exactly this way, but you canglean an input state, an opperation string and an output state from this example:
[[
:insert-using-01 a mf:UpdateEvaluationTest ;
    mf:action [
       ut:request <insert-using-01.ru> ; 
                ut:data <insert-using-01-pre.ttl> ;
                  ut:graphData [ ut:graph <insert-using-01-g1-pre.ttl> ;
                               rdfs:label "http://example.org/g1" ] ;
                  ut:graphData [ ut:graph <insert-using-01-g2-pre.ttl> ;
                               rdfs:label "http://example.org/g2" ] ;
              ] ;
    mf:result [
                ut:data <insert-using-01-post.ttl> ;
                  ut:graphData [ ut:graph <insert-using-01-g1-post.ttl> ;
                               rdfs:label "http://example.org/g1" ] ;
                  ut:graphData [ ut:graph <insert-using-01-g2-post.ttl> ;
                               rdfs:label "http://example.org/g2" ] ;
            ] ;
    .
]] <http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/manifest.ttl>

The SPARQL Update semantics <http://www.w3.org/TR/sparql11-update/#formalModel> says "A Graph Store GS is a mutable container of RDF graphs [with] one unnamed (default) slot and zero or more named slots."
So for update purposes, a graph store is a collection of named and unnamed slots.
The document uses this notation for a graph store:

  GS = {DG, (iri1, G1), ... , (irin, Gn) }

An opperation maps one graph store to another, creating and removing slots and creating, removing or altering the contents of the graphs in those slots.
In SPARQL, a dataset is a set of graphs <http://www.w3.org/TR/sparql11-query/#sparqlDataset>:

  DS = { G, (<u1>, G1), (<u2>, G2), . . . (<un>, Gn) }

This is summarized in <http://www.w3.org/TR/sparql11-update/#defn_graphStore> as "The Graph Store can be viewed as a mutable RDF Dataset."
Both specs rely on some supporting functions like DIFFs and UNIONs to help define the eval(dataset, query)->result set or eval(, update)->dataset.

It's likely that Linked Data Profile will require similar semantics, perhaps with some abstracts around containers <http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/#bpc> to say e.g.

  A Membership is a sequence of gboxs containing triples associating each document in a set of documents with a "membership subject". The "membership predicate" ... mumble mumble foo.
  For each (IRIⁿ, gboxⁿ) in the sequence of gboxes, gboxⁿ contains the triple { <IRIⁿ> bp:pageOf <membership subject> }.
  For each gboxⁿ except the last, gboxⁿ contains the triple { <IRIⁿ> bp:nextPage <IRIⁿ+1> }.

The above definition is an example where we care about the difference between a named graph and a named graph gbox. That's why I said "gbox".
This is the sort of foundational semantics and notation support I expect of a named graphs semantics.


> > Perhaps we should not define a graph to BE a set, but rather define it
> > to be any RDF document or structure which *parses* to a set. So we keep
> > the idea of the set-based abstract syntax, but we morph the terminology
> > to be more in line with the way most of the world actually speaks and
> > thinks.
> 
> +1
> 
> 
> > Under this proposal (which, to emphasise, is purely one of terminology,
> > not actual content) we would say that an RDF/XML or an Ntriples
> > document actually *is* an RDF graph.
> 
> Well, to be clear, it is a representation of an RDF graph, isn't it?
> 
> 
> > And when a URI resolves to such a
> > thing, we say that it resolves to a graph; and when people talk of
> > adding triples to a graph, we smile benignly instead of throwing a
> > hissy fit. (Of course, this changes the graph: it is now a different
> > graph, once one has made a change to it: but still, it is a graph.) And
> > now the labile/fixed contrast becomes a fairly standard and easy-to-
> > accept contrast between things that are allowed to change and things
> > that, for some reason, are not, instead of being a contrast between two
> > fundamentally different *kinds* of thing. And then the only people who
> > need to talk about mathematical sets at all, would be people checking
> > that parsers work properly.
> 
> +1
> 
> 
> > It would take us a while to get used to this change, but I think that
> > once we had gotten used to it, we and everyone else would feel a great
> > sense of relief. And Richard and myself would have to rewrite parts of
> > the Concepts and Semantics text, but again I dont think it would be
> > very difficult.
> > 
> > Comments?
> 
> I really like this proposal as it brings the terminology much closer to
> other Web architecture terminology... I think it would be well worth the
> effort.
> 
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 

-- 
-ericP

Received on Monday, 20 August 2012 13:30:48 UTC