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

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:04:54 UTC