Re: What is really a graph container? Re: more about dereference (notes from MIT post F2F2-day-1)

Pierre-Antoine,

W.r.t to the graph terminology we made a decision at the F2F which is 
now an WG resolution. We should really take resolutions seriously, 
meaning we avoid re-opening the discussion, unless we have new evidence. 
  This resolution is clearly the outcome of a compromise, but we also 
agreed to clearly mark this terminology in our documents and explicitly 
request feedback on it from the community.

I hope you can live with this for the time being.

Best,
Guus


On 19-10-2011 09:19, Pierre-Antoine Champin wrote:
> Ok, here is another idea:
>
> we keep "graph container" as a rather vague notion, just to point out
> that many thing that one is tempted to call a "graph" are actually
> something else. Then we illustrate that notion with two particular kinds
> of graph containers, more precisely defined:
>
>    a *graph slot* is a mutable object whose state is (a representation
>    of) an RDF graph. In other words, it provides a function from time to
>    RDF graphs.
>      (e.g. an .ttl file, an instance of jena.rdf.model.Model)
>
>    a *graph web resource* is a web resource whose representations are
>    graph serializations (fka g-texts)
>      (e.g. my FOAF profile, facebook RDF exports)
>
> The definitions overlap: my FOAF profile is managed as a file, and only
> varies with time, so it is both a graph slot and a graph web resource.
>
> They are not identical, because some graph web resources can return
> different graphs at the same time, depending on other factors
> (authentication, language negotiation?,...).
>
>    pa
>
> PS: I'm not completely convinced by "graph slot" as a term, but it seems
> to me that it holds the idea that it contains only a *single* graph at a
> given time. In addition, it is already used by the DAWG, in a way that
> seems compatible with this notion.
>
>
> On 10/19/2011 09:03 AM, Pierre-Antoine Champin wrote:
>> Sandro,
>>
>> my point is not to "dismiss" the facebook example, nor to tell facebook
>> they should do things differently.
>>
>> My concern is that we can either:
>>
>> * keep a restrictive definition of "graph container", relying on the
>> notion of *state*, and in that case the facebook example does not fit
>> the definition (which does not mean it is uninteresting or incorrect!);
>>
>> * define "graph container" is broader sense that include the facebook
>> example, like "anything that, when poked, returns an RDF graph"
>>
>> Note that I use the fuzzy term "poke" (suggested by Pat in a previous
>> conversation) rather than "dereference", because I want the definition
>> to apply in a "non-web" context (namely, I would like an instance of
>> rdflib.Graph or jena.rdf.model.Model to be considered a graph container).
>>
>> But this fuzziness in terms makes virtually anything a graph container
>> -- even *I* can produce an RDF graph if you poke me. Does that make me
>> graph container??
>>
>> So, my concern is that, with too broad a definition, the notion becomes
>> fuzzy, too general and potentially useless. This is just an intuition,
>> though. And on the other hand, keeping a restrictive definition for
>> graph container does not mean that anything that does not fit that
>> definition is uninteresting.
>>
>>    pa
>>
>>
>> On 10/15/2011 03:41 AM, Sandro Hawke wrote:
>>> On Fri, 2011-10-14 at 16:52 +0100, Pierre-Antoine Champin wrote:
>>>> This is a reaction to Richard's question below...
>>>>
>>>> On 10/13/2011 12:16 PM, Richard Cyganiak wrote:
>>>>> On 12 Oct 2011, at 22:04, Sandro Hawke wrote:
>>>>>> 1. If a system successfully dereferences URL "L" and obtains a
>>>>>> representation of an RDF graph, then<L>  is a GraphContainer.  That
>>>>>> is, "L" denotes a GraphContainer.  Logically, GraphContainer is
>>>>>> disjoint from foaf:Person (I think!!) so a document that includes "<>
>>>>>> a foaf:Person" is (by this proposal) logically inconsistent with it
>>>>>> being served on the Web.
>>>>>
>>>>> This seems a logical consequence from httpRange-14.
>>>>
>>>> At first I agreed, but depending how you precisely define a graph
>>>> container, it may not be true. See below...
>>>>
>>>>>> 2. So, owl:Ontology heavily overlaps GraphContainer.  It might even be
>>>>>> a subclass of it.  (Many OWL ontologies say "<>  a owl:Ontology", where
>>>>>> the<>  will be resolved to the address the ontologies is fetched from,
>>>>>> aka L.)
>>>>>
>>>>> Well, sort of. They are orthogonal by definition, but overlap in practice because it can be useful to treat owl:Ontologies as graph containers.
>>>>>
>>>>>> 3. Some GraphContainers, "SerialGraphContainers" are functions mapping
>>>>>> from time to RDF Graphs.  We can talk about next&  previous&  current
>>>>>> RDF Graphs in a SerialGraphContainer, but not about GraphContainers in
>>>>>> general.  (cf facebook's api for fetching RDF data, which returns
>>>>>> different RDF data depending on your credentials).
>>>>>
>>>>> I don't understand that. If graph containers are mutable, then doesn't that already mean they are functions mapping from time to RDF graphs?
>>>>
>>>> Well, as I understood it, we have defined a graph container as something
>>>> whose state is an RDF graph; for me, "state" reads "a function from time
>>>> to X", so I concur with Richard: the definition SerialGraphContainers
>>>> should apply GraphContainer.
>>>>
>>>> However, I see where Sandro is coming from: see the facebook example he
>>>> gives above. However, if Facebook returns different *graphs* for the
>>>> same resource at the same time, depending on another parameter
>>>> (credential), then the *state* of the resource is *not* an RDF graph, it
>>>> is something more (a "graph+ACL" or something like that).
>>>>
>>>> Hence, if that resource (in the RESTest sense) has a state which is not
>>>> a graph, this is not a graph container as we defined it. QED.
>>>>
>>>>
>>>> Of course, we could extend our definition so that it encompasses
>>>> X-varying graph containers (where X can be "credential", "location",
>>>> ...) but the open nature of X makes it the definition very generic, may
>>>> be too much...
>>>>
>>>> So my reaction would be to stick to the safe side and restrict "Graph
>>>> Containers" to vary with time only. Of course, many other things may
>>>> "hold" graphs in different fashions that depend on other factors, but
>>>> this WG can/should not define all of them.
>>>
>>> Your proof sounds good on paper, but I don't think you can dismiss the
>>> facebook example so simply.   Yes, we can say their thing isn't a
>>> GraphContainer, via the web that's it's not, since we did a deref and
>>> got back an RDF graph.  :-(
>>>
>>> I suppose one could ask them to redirect to parameterized URIs, so I ask
>>> for:
>>>        http://my.example.com    (not a GraphContainer)
>>> when logged in as sandro and it redirects (302 FOUND) to
>>>        http://example.com/sandro/    (a GraphContainer)
>>> and then gives me the content.
>>>
>>> But I'm guessing facebook (and others) aren't willing to burden their
>>> users with an extra round trip just for this kind of architectural
>>> purism.   (Some people will like to use the second form URI, but not
>>> everyone wants to bother.)
>>>
>>> Another technical/http solution:
>>>
>>> I ask for http://my.example.com and get the response, but it includes a
>>> "Content-Location: http://example.com/sandro/" header.   The client
>>> could use that header as a flag to indicate the URL that really denotes
>>> that GraphContainer.   And if facebook doesn't include such a header it
>>> would just be ... "broken".    Yeah, that might work.
>>>
>>> I don't know how widely Content-Location is used.  I know w3.org uses it
>>> a lot, but I don't know about the web at large.   The Google results I
>>> see for it suggest it's not widely used, but maybe that's okay.  It
>>> seems pretty ReSTful to me.
>>>
>>> One final note -- giving a quick look at the facebook API, I don't
>>> actually see this kind of URL where each person sees a totally different
>>> thing.   Someone said in the meeting they do that; even if they don't,
>>> surely someone else does or will.   What I do see is this:
>>>
>>> GET -H 'Accept: text/turtle' https://graph.facebook.com/sandro.hawke
>>>
>>>      -- Sandro
>>>
>>>>      pa
>>>>
>>>>
>>>>
>>>>>
>>>>>> 4. A ConstantGraphContainer always holds the same RDF Graph.  This can
>>>>>> be used for when you want to attach a dereferenceable URL to a g-snap.
>>>>>> You put it in a ConstantGraphContainer.
>>>>>
>>>>> Seems reasonable.
>>>>>
>>>>> Richard
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Received on Wednesday, 19 October 2011 14:52:46 UTC