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

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 07:20:03 UTC