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

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 Saturday, 15 October 2011 01:41:47 UTC