W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2012

Re: Drop “g-boxes”, talk about “stateful resources”

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 22 May 2012 13:30:02 -0400
Message-ID: <4FBBCD1A.4030204@openlinksw.com>
To: public-rdf-wg@w3.org
On 5/22/12 10:54 AM, 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.)


Yes, the "RDF" qualification is important. Just as "Web" for "Web 
Resource" is also important when speaking generally about Web medium 



Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Tuesday, 22 May 2012 17:30:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:18 UTC