- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 21 Nov 2012 09:25:29 -0500
- 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>
- Message-ID: <50ACE459.8090100@openlinksw.com>
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 :-) -- Regards, 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 21 November 2012 14:26:06 UTC