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

On Fri, Oct 14, 2011 at 6:41 PM, Sandro Hawke <sandro@w3.org> 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.

That would be me. I thought the graph api worked the same way as their
other APIs which use a cookie, however the graph API does NOT.

>  What I do see is this:
>
> GET -H 'Accept: text/turtle' https://graph.facebook.com/sandro.hawke

Facebook example it turns out is a bit more complicated, and I think
DOES work. Eg, they placed the access token into the URI.

$ curl -H "Accept: text/turtle" http://graph.facebook.com/me/
@prefix : <http://graph.facebook.com/schema/~/> .
_:error
        :error [
                        :message "An active access token must be used
to query information about the current user." ;
                        :type "OAuthException" ] .


If you add: ?access_token={token}

You would get a graph which is contextualized by the Facebook
Application and the currently authorized user. That URI will be
unique. To keep that context info the application would have to store
data about the OAuth 2.0 request that created the token, but that
doesn't seem incorrect. The access_token can be added to any of those
Graph URIs. Of course, that creates a new issue, in that the links
between graphs all use the non authenticated URIs which are DIFFERENT
then the URIs of the authenticated graphs.

--Gavin

>
>    -- 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 02:00:22 UTC