- From: Sampo Syreeni <decoy@iki.fi>
- Date: Fri, 15 Jan 2010 21:28:45 +0200 (EET)
- To: Danny Ayers <danny.ayers@gmail.com>
- cc: Michael Schneider <schneid@fzi.de>, Jiří Procházka <ojirio@gmail.com>, Semantic Web <semantic-web@w3.org>
On 2010-01-15, Danny Ayers wrote: > "Optional" is a very good word, about perfect for such stuff. Very much so. It isn't a given that everybody utilizing the RDF framework should need containers, or reification, or... But there is also a grave danger lurking around this sort of thought pattern. We do need and want standardization, after all. Especially with the core primitives. True, not everybody wants to implement every primitive, but if and when they do, we'd like them to implement them in a common way, so that we could share structure using common API's, representations and so on. So, even if we externalize/excise something from the core RDF spec, it still needs to remain a standard, and the same problem we had within the core spec remains. It just has to be confronted at a different forum. When we do something like this, we don't just cast out stuff that is difficult to handle; instead we modularize the spec, and when we do that, the dissension isn't eliminated, but only moved to a different venue. I for one would like to see much *more* contentious structure brought under a standardization effort. The relational-RDF-mapping effort going on under W3 is just one example (a dear one to me). There I simply *cannot* understand why they're trying to cater to all of the crowds at the same time by defining *yet* another intermediary language. Why can't they just define a single, canonical mapping from relational to RDF?!? Sure, there is always political hassle, and even the occasional standoff; but in politics they already deviced a workable tie-breaker. That is to say, assassination. After seeing (just) a couple of committee meeting online and off, I'm seriously warming upto the idea... -- Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Friday, 15 January 2010 19:29:26 UTC