Re: A radical proposal.

On 08/20/2012 11:02 AM, Pat Hayes wrote:
> On Aug 20, 2012, at 8:30 AM, Eric Prud'hommeaux wrote:
>
>> * 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.
> It isnt supposed to change it at all, only the terminology.
>
>> 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
> Yes to 1 and 2, but I think that most people outside the WG and even the WG at weekends already think about RDF on the Web this way.
>
>> ?
>>
>> 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).
> Let me try the idea explicilty. We have become very, very careful to distinguish mathematical RDF graphs from concrete, mutable, data that encodes RDF graphs (things like RDF/XML or Ntriples documents.). All I am suggesting it, now we all have our ideas clear, that we can afford to be sloppy in using the terminology, and call them all just "graphs", and distinguish "fixed graphs" from "mutable graphs" when we need to be careful about that distinction, and distinguish "graph resources" (or RDF spaces or g-boxes) from "abstract graphs" when (more rarely) we need to be careful about that distinction, but most of the time we don't need to be careful, in fact, and neither does anyone else, so we can just use "graph" for everything until someone asks us to be more precise, and the sky will not fall.

+1.   Yes, let's be okay with the term "graph" (even RDF Graph) being 
fuzzy .    And yes, we should probably have terminology for use when we 
don't want to be fuzzy, like "abstract graph".

An analogy might be how programmers use the word "string". Sometimes 
they're referring to a section of memory, sometimes they're referring to 
an abstract sequence of characters.   Equality and mutability and 
character-encoding are important issues, but often we can ignore them 
and just think of strings.

If it wouldn't cause SPARQL too many problems, I'd suggest we should do 
the same with dataset, and even allow a dataset to be a kind of graph, I 
think, so that the world at large can use the word term "RDF dataset" 
for any collection of RDF data (whether or not it's segmented into named 
graphs).

        -- Sandro

>> 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 meant only that we would need some editorial changes to the documents. Not just an email agreement.
>
>>
>>> 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.
> Right. This is a good example of a place where we need to be very picky and careful with our language, and make distinctions like between abstract graph and graph "slots" or whatever we call them. BUt most of the time we don't have to be that careful. And even here, the SPARQL 1.1 talks about "mutable RDF dataset" which strictly speaking is an oxymoron.
>
>> 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.
> I agree that the semantics should be very precise about what exactly is being named by a 'graph name'.
>
> Pat
>
>>
>>>> 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
>>
>>
> ------------------------------------------------------------
> 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 Monday, 20 August 2012 15:30:41 UTC