- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Wed, 19 Oct 2011 18:12:01 +0200
- To: Guus Schreiber <guus.schreiber@vu.nl>
- CC: public-rdf-wg <public-rdf-wg@w3.org>
Guus, Sorry if I sounded like I was neglecting the F2F resolution; my understanding is that we resolved to use a more user-friendly terminology in lieu of the g-* terminology. I did not intend to question that. However, from the emails exchanged in this thread (between Sandro and Richard, or between Pat and Dan), it seems to me that we still fail to agree about what is or is not a "graph container" (or "g-box" for that matter). Namely, Sandro seems to ha however, we still seem to disagree on what is or is not a "graph container/g-box", from e-mail exchanges on this thread between Sandro and Richard, or Pat and Dan... So I was mainly trying to help finding a consensus *beyond* the one reached at the F2F. But I sincerely apologize if I appeared to muddy the water instead. pa On 10/19/2011 04:52 PM, Guus Schreiber wrote: > Pierre-Antoine, > > W.r.t to the graph terminology we made a decision at the F2F which is > now an WG resolution. We should really take resolutions seriously, > meaning we avoid re-opening the discussion, unless we have new evidence. > This resolution is clearly the outcome of a compromise, but we also > agreed to clearly mark this terminology in our documents and explicitly > request feedback on it from the community. > > I hope you can live with this for the time being. > > Best, > Guus > > > On 19-10-2011 09:19, Pierre-Antoine Champin wrote: >> 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 16:12:48 UTC