- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 22 May 2012 19:44:55 -0500
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: RDF Working Group WG <public-rdf-wg@w3.org>
On May 22, 2012, at 6:08 PM, Richard Cyganiak wrote: > On 22 May 2012, at 15:54, Pat Hayes 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".) > > It sounds lovely to me. Well, the more I read the alternatives, the better it gets, I have to admit. > >> And its not RDF-specific enough. > > That's intentional. It tries to align naturally with REST and web architecture. Why can't it do that and still be RDF-specific? After all, this is supposed to be the concept which replaces "graph container" in our RDF documents, not part of some grand theory of the Web. (Right?) > >> 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? > > Well, yeah. But this is hard to fix. > > The alternative would be to use some other term from REST or something more obviously technical. I toyed with “representable resource” earlier (something that can have a representation, in the REST sense) but I'm sure that you'd object to that one equally. I also proposed “graph state resource” earlier in the WG's lifetime but this, while a fairly accurate term, is too bland to stick. > > So I'll stick with “stateful resource” for now. > >> (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.) > > +1 > >> "stateful RDF resource" would be better. > > But anything can be an RDF resource, and many things can have state, so this is no better than “stateful resource”. Well, it still has THAT problem, but it does at least distinguish things that emit RDF from, say, plain old HTML or an embedded JPEG. (If you want to cover all these bases, then we will need to have another name for the things that emit RDF graph representations, as opposed to all the other resources in the REST architecture.) > >> 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.) > > A “fixed” RDF graph-emitting thingie would be an “immutable stateful resource”. Blech. To me that reads like an "unchanging changeable thing". > Statefulness doesn't necessarily imply change; it refers to the capability of holding state. Now you really have lost me. What entity in any possible universe does NOT have the capability of holding state? Simply to exist is to "hold a state", unless this phrase has some meaning in a theory that I have no knowledge of. I have been assuming that we say that something has a state when its 'behavior' (In some very abstract sense) might depend upon this state, ie when it is not something which is fixed and unchanging. In fact, the very notion of "state" is a kind of theoretical fiction invented to account for the fact that the same thing can 'behave' in different ways on various occassions. > In REST it's specifically about having some sort of internal state that can be expressed in a representation. A “normal” resource would be one of which we make no claim of having such internal state. This sounds like a three-way distinction: things without a(n internal) state; things with a state, but this state is fixed; things with a changable state. I see no reason for having the first distinction, and I don't find it meaningful. Pat > Richard > > > >>> == 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
Received on Wednesday, 23 May 2012 00:45:51 UTC