W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: RDF-ISSUE-110 (g-box): A proper term for the concept formerly known as ?g-box?? [RDF Concepts]

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 21 Nov 2012 09:25:29 -0500
Message-ID: <50ACE459.8090100@openlinksw.com>
To: Thomas Baker <tom@tombaker.org>
CC: public-rdf-wg@w3.org, "public-rww@w3.org" <public-rww@w3.org>, "public-webid@w3.org" <public-webid@w3.org>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
On 11/20/12 11:53 PM, Thomas Baker wrote:
> On Tue, Nov 20, 2012 at 09:51:40PM -0500, Kingsley Idehen wrote:
>>> Tom, the reason we can't give you a *definition* of the concept is that it
>>> is a natural kind term. We didn't invent this idea; it isn't ours to define.
>>> We just observed that, out there in the real world, there were by now a lot
>>> of things that stored RDF or emitted RDF representations when suitably
>>> poked, and were identified by IRIs, or at any rate thought of as having an
>>> enduring identity, and yet were labile, in that sense that the actual RDF
>>> they contained/emitted/whatever might vary with time. Because they are
>>> labile, they can't be called RDF graphs (even though a lot of people were
>>> calling them that.) Because they are real things that people identify and
>>> use, we want to be able to refer to them, so we need a single overarching
>>> name for the general concept. So, just as with "resource" and "document" and
>>> "HTTP endpoint" and many other terms of art, we don't actually give a
>>> *definition* of them, because once anyone gives a definition they fix the
>>> meaning in stone and thereby exclude things that one might want to include
>>> but had not thought of, or had not encountered, when the definition was
>>> written. We thought of a number of evocative names (g-box, RDF document, rdf
>>> surface) but they all were seen as too limiting, as tending to exclude some
>>> useful cases (eg 'document' suggests something essentially textual, but an
>>> RDF Source could be a process which scours RDFa from Web pages on demand)
>>> and so the deliberately bland, uniformative term was chosen. Again, this is
>>> a frequently used strategy in such circumstances. (The W3C could have save
>>> itself a lot of grief if it had used the bland word "thing" instead of the
>>> jazzier term "resource".)
>>> Seems to me that the phrasing used by Richard, viz, "persistent but mutable"
>>> resources which emit RDF representations, is right on the mark. If you want
>>> a definition, that is the best you can ever get. So, if you have something
>>> that emits RDF when poked, is going to last for a while (so you might want
>>> to identify it with a URI) , and is liable to emit different RDF at
>>> different times (or even if not, if it is for other reasons the same *kind*
>>> of thing as one that could be mutable in this sense), then whatever else it
>>> happens to be, and however you implement it, it is an RDF Source.
>> Great summary!
>> If you don't mind, I've cc'd in some other RDF dependent groups that could
>> benefit from the explanation above.
> Great indeed!  This is exactly the explanation I was looking for!  It
> acknowledges that for alot of people, "RDF graphs" evokes things that are
> mutable, and it explains why Richard's minimal "definition" may be the best one
> can do.  IMO, that story somehow needs to be part of the WG's message.
> Tom

Yes! How that actually happens, is another matter though :-)



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 Wednesday, 21 November 2012 14:26:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:33 UTC