- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 24 May 2012 09:16:50 +0200
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Richard Cyganiak <richard@cyganiak.de>, Guus Schreiber <guus.schreiber@vu.nl>, <public-rdf-wg@w3.org>
Not wanting to enter the HTTPRange-14 discussion (although I have the feeling that we are getting dangerously close to it sometimes), I wonder whether Jeni's long blog is not relevant here: http://www.jenitennison.com/blog/node/170 Ivan On May 24, 2012, at 03:06 , Pat Hayes wrote: > Mostly I agree with you, Richard, but one point I can't let slide by. > > On May 23, 2012, at 6:56 PM, Richard Cyganiak wrote: > >> Hi Guus, >> >> On 23 May 2012, at 15:12, Guus Schreiber wrote: >>> Putting on my hat as Primer editor I'm not sure the proposed new term is going to fly. The rationale you give for "stateful resource" makes a lot of sense from the REST perspective, but for me it won't work to explain the notion to a broader audience (especially given the RDF use of the term "resource"). >> >> I'd like to see an example that shows this difficulty. > > The RDF usage of "resource" for "anything that can be referred to" does make any usage which restricts it this seriously rather problematic. We have had this problem now for at least 9 years. > >> >>> Although strictly speaking "graph container" is slightly different from the intendeed meaning of "stateful resource", the notions are very close. >> >> There are many things that can be said to have a state that can be expressed in RDF, but that definitely are not containers of RDF graphs. People, for example. Or HTML web pages with embedded RDFa. > > Whoa. We have to distinguish being described by RDF, and being a source of RDF syntax. Of course there are any number of things with state that can be described using RDF: people, for example. (In fact, probably just about anything.) Here for example is one way to describe people's ages using RDF: > > Bill :hasState [ > a :PersonState > :date "2012_01_01"^^xsd:date > :age "51"^^xsd:integer ] > > and I'm sure we can think of some others. But people are not things that emit RDF graphs. Most people know absolutely nothing at all about RDF triples and will never even think of the concept during their entire lives. They do not emit or produce or deliver RDF graphs under any circumstances whatever. HTML web pages with embedded RDFa do do this, but I see no reason why we can't think of such an HTML page as a "container" of RDF. Indeed, that seems very natural. Basically, the intuition is that if you can get xxx out of it, then it is a container of xxx. > >>> Graph container is a term I could see myself using to explain to a broad audience exactly what you're speaking about, and I would likely add a note that, from a REST perspective, this can be seen as the state of an RDF "resource". The nice thing about "graph container" is that it builds on an intuition that many people can relate to, as I have seen in discussions with WG outsiders over the past year. >> >> Well, of course it's easy to explain the notion of a container of triples as an isolated example. But if this notion doesn't match what we need to do with RDF datasets in the real world, then it matters little if it is easy to explain. > > Can you give one example of something that we need to describe as a stateful resource but isn't naturally conceptualized as an RDF container? In my world, pepole are not the former and HTML/RDFa pages are the latter, so got any more? > > Pat > > >> >>> This puts a heavy burden on any term that is intended to replace it. >> >> I disagree with the notion that “stateful resource” is a new term intended to “replace” the existing term “graph container”. The starting point for the graph abstract syntax is SPARQL. SPARQL has “RDF datasets” and “named graphs”. *That* are the existing terms. The g-* terminology and the replacements we resolved to use instead are terms for discussion, to disambiguate the various meanings of “graph”. They are not our data model. >> >> Best, >> Richard >> >> >> >> >> >>> >>> My two cents .... >>> Guus >>> >>> [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0372.html >>> [2] http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0196.html >>> >>> On 23-05-2012 13:41, Pat Hayes wrote: >>>> >>>> On May 23, 2012, at 3:04 AM, Andy Seaborne wrote: >>>> >>>>> >>>>> >>>>> On 23/05/12 01:29, Pat Hayes wrote: >>>>>> >>>>>> On May 22, 2012, at 12:27 PM, Andy Seaborne wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 22/05/12 15:54, Pat Hayes wrote: >>>>>>>> >>>>>>>> On May 22, 2012, at 6:53 AM, Richard Cyganiak wrote: >>>>>>>> >>>>>>>>> This is a proposal to drop the term “g-box” from our graph vocabulary, along with all the other terms it has inspired such as “layer” or “space”, and use the term “stateful resource” instead. >>>>>>>> >>>>>>>> I like the idea behind this and the reasoning in support of it, but I find this actual term ugly, just on literary criteria. (It sounds like the resource if full of state, like "boastful resource".) And its not RDF-specific enough. Also, since anything can be a resource, and since many things in the universe can have a state, this casts the net far too widely. For example, the brick I use as a paperweight is a resource, and it has a state (it gets warmer when the sun shines on it) so is it a stateful resource? (There is a real disconnect here between the REST meaning of "resource" and what was in 2004 the TAG usage of the word, now firmly set in stone in the RDF specs. This is now ancient Web history, but the disconnect still irritates.) >>>>>>>> >>>>>>>> "stateful RDF resource" would be better. Then an "RDF resource" can be a non-stateful version, ie a 'fixed' RDF graph-emitting thingie, which is a concept we do need. (Whereas, to point out the obvious, we can hardly just use "resource" for this.) >>>>>>>> >>>>>>> >>>>>>> I'm not sure we want to be RDF specific. >>>>>> >>>>>> Um... we are the RDF WG, right? >>>>> >>>>> And it's the semantic *web*? >>>> >>>> But its not our job to define the entire Web or even the entire semantic web. We are the RDF WG, not the SWeb WG. >>>> >>>>> >>>>>>> It's too black/white. Some state is exposed as RDF, and maybe that's zero triples. I'm sure we'd like to think its going to change. >>>>>> >>>>>> Im not following you here, Im afraid. >>>>> >>>>> I just find "RDF resource" coming with an implication there is the RDF world and there are other worlds and ne'er the twain shall meet. >>>> >>>> I didnt even consider that interpretation. Does "HTML resource" imply that there is a separate HTML world? "RDF resource" is a resource that emits some RDF, is all. Not all of them do, and we have nothing to say about the ones that don't. >>>> >>>>> >>>>>>> An RDFa document is not primarily seen as an RDF syntax but is a source of triples. >>>>>> >>>>>> Exactly, a source of RDF triples. So, an RDF resource. It might be other things as well, but looked at through RDF glasses, its a thing which emits triples when prodded suitably. >>>>>> >>>>>>> Other HTML documents, like bricks, are simply without triples. >>>>>> >>>>>> And so they are not RDF resources. >>>>>> >>>>>> All makes sense to me :-) >>>>> >>>>> Don't make the empty graph a special case :-) >>>> >>>> So, let me understand. EVERYTHING emits an RDF graph when poked, but some (most) of them, we will say, emit the empty graph, by not emitting anything or by refusing to cooperate. Is that the picture? That does make a kind of zany sense, but it strikes me as moderately insane. It is like saying everyone speaks Swahili, but some of them speak only empty Swahili. >>>> >>>> The empty graph IS a special case, after all. >>>> >>>> Pat >>>> >>>>> >>>>> Andy >>>>> >>>>>> >>>>>> Pat >>>>>> >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>>>> == The container metaphor is unhelpful == >>>>>>>>> >>>>>>>>> The terms “g-box”, “space”, “layer” and so on all follow a “container metaphor”. >>>>>>>> >>>>>>>> FWIW I don't read "layer" or "space" as based on the container metaphor, myself. >>>>>>>> >>>>>>>> Pat >>>>>>>> >>>>>>>> >>>>>>>>> This seems like an obvious one to use. After all, what are RDF stores if not containers of triples? And isn't an RDF file just a container of triples? But my conclusion is that thinking about this in terms of containers is a mistake and is taking us down a dead-end. It doesn't match current (and conforming) SPARQL use. It doesn't work well for many use cases. It is disconnected from the terminology of REST. And it is plainly not how the web works. >>>>>>>>> >>>>>>>>> >>>>>>>>> == Stateful resources == >>>>>>>>> >>>>>>>>> So let's forget about g-boxes and let's talk about *stateful resources* instead. >>>>>>>>> >>>>>>>>> Stateful resources are resources that have an associated state, and the state can be expressed as an RDF graph. We can accept the intuition that the state of a resource may change over time, and that it only has one state at any given time. A stateful resource doesn't necessarily ever have to change—it can be immutable. Since anyone can say anything about anything, there is nothing wrong with a resource whose state is a graph that contains a bunch of nonsense—that's an application problem, and we are defining infrastructure. >>>>>>>>> >>>>>>>>> This is exactly what the word “resource” means outside of RDF (in REST, short for REpresentational *State* Transfer). >>>>>>>>> >>>>>>>>> >>>>>>>>> == What kinds of resources can have state? == >>>>>>>>> >>>>>>>>> I will purposefully avoid the question what sorts of things can have state, and what exactly may or may not be a reasonable state for particular kinds of resources. We can accept whatever answer works for REST. >>>>>>>>> >>>>>>>>> But it is certainly the case that, if we dereference an IRI i and get back a 200 status code along with a representation that encodes an RDF graph G, then it would be reasonable to conclude that G is the state of (the resource denoted by) i. >>>>>>>>> >>>>>>>>> Although for some use cases, some users would likely want to use other, non-standard, “state functions”, and that's ok as long as they're in their own closed environment. >>>>>>>>> >>>>>>>>> >>>>>>>>> == Extending the terminology == >>>>>>>>> >>>>>>>>> This naturally leads to a complete set of terminology (if we find that we need it). >>>>>>>>> >>>>>>>>> *If* we want to be explicit about the denotations of the IRIs in<IRI,graph> pairs in RDF datasets, then let's say they denote *stateful resources*. >>>>>>>>> >>>>>>>>> *If* we want to define a class for that, let's call it *rdf:StatefulResource*. >>>>>>>>> >>>>>>>>> *If* we want to define a name for the<IRI,graph> pairs other than “named graph”, then let's call them *state pairs*. >>>>>>>>> >>>>>>>>> *If* we want to give a name to the relationship that holds between the IRIs and graphs in these pairs, let's call it the *state relationship* or *state function*. >>>>>>>>> >>>>>>>>> *If* we want to define this relationship as an RDF property, let's call it *rdf:state*. >>>>>>>>> >>>>>>>>> We *could* define RDF dataset as “a default graph and zero or more state pairs, max. one per IRI.” >>>>>>>>> >>>>>>>>> >>>>>>>>> == How this is better == >>>>>>>>> >>>>>>>>> * It matches REST's notions of Resource and State. >>>>>>>>> >>>>>>>>> * Weird uses of SPARQL named graphs can be explained simply as “using a non-standard state function”. >>>>>>>>> >>>>>>>>> * It works even if you don't believe in httpRange-14; in this case, a person for example becomes a “stateful resource” that may have an RDF graph describing her associated via rdf:state. That sounds much less jarring than claiming that a person is a “g-box” or a “container of triples” or a “layer” or “space”. >>>>>>>>> >>>>>>>>> * It works even with real-world web scenarios where servers return different content to different clients, e.g., depending on authentication or on Accept-Language content negotiation; we just have a state function that is different depending on who the client is. >>>>>>>>> >>>>>>>>> * Other specifications can easily put conformance constraints on the state function: “In an XYZ-dataset, the state function that associates graphs with IRIs MUST be: derefencing with an Accept header asking for RDF/XML, and parsing any 200-result as RDF/XML.” >>>>>>>>> >>>>>>>>> * It avoids the mistake that the TAG made when they defined “information resource” by appealing to the “nature” of the resource. >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>>>> IHMC (850)434 8903 or (650)494 3973 >>>>>>>> 40 South Alcaniz St. (850)202 4416 office >>>>>>>> Pensacola (850)202 4440 fax >>>>>>>> FL 32502 (850)291 0667 mobile >>>>>>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------ >>>>>> IHMC (850)434 8903 or (650)494 3973 >>>>>> 40 South Alcaniz St. (850)202 4416 office >>>>>> Pensacola (850)202 4440 fax >>>>>> FL 32502 (850)291 0667 mobile >>>>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> ------------------------------------------------------------ >>>> IHMC (850)434 8903 or (650)494 3973 >>>> 40 South Alcaniz St. (850)202 4416 office >>>> Pensacola (850)202 4440 fax >>>> FL 32502 (850)291 0667 mobile >>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > > ------------------------------------------------------------ > IHMC (850)434 8903 or (650)494 3973 > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile > phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > > > > > > ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Thursday, 24 May 2012 07:13:27 UTC