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

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.

    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 Friday, 14 October 2011 21:03:37 UTC