- From: Jeremy Gray <jeremy@jeremygray.ca>
- Date: Sun, 9 Jun 2002 14:44:39 -0700
- To: "'Uche Ogbuji'" <uche.ogbuji@fourthought.com>
- Cc: <www-rdf-interest@w3.org>
Thanks for your response. I've read a number of your articles and have followed many of your postings on this and other mailing lists and I really appreciate you taking the time to read and respond to my post. It sounds like we're basically on the same page with regards to the issue, so I've just made a few comments inline: (snipped text re: requiring explicit namespace prefixes on attributes) > I get nowhere with this argument. Members of the RDF Core WG effectively told > me: you're too late; we've made our decision; we don't expect to revisit it; > deal with it. So I'm dealing with it. It is very easy to both produce and consume RDF/XML which does comply with the WG position on the issue, so I guess the real question would be whether or not to additionally support the parsing of RDF/XML with implicitly-namespaced attributes, possibly with the ability to disable such behaviour for purposes of strict validation. How are your products implemented in these regards? > RDF/XML does make this matter awkward, but again I think it would be > too strong a statement to say that RDF/XML makes naming collisions inevitable. Inevitable, no. You are quite correct to point out that in most cases collisions will only occur within oddly-defined patterns of identifiers, so I guess we'll just have to see how well things hold up once RDF applications begin interacting with large quantities and ranges of information. When someone else's namespace and identifiers cause a collision to happen, however, I doubt either you or I would enjoy being the vendor that incurs the customer's wrath. (snipped a chunk re: the problems with the recommended splitting algo) > I think the WG desperately needs to fix this. Yes. Even more than the concatenation issue, and for a number of reasons. It's obvious that RDF applications can extract value from existing systems, but until the reverse can be made true we're not going to see large-scale adoption of RDF in the industry. People don't rebuild systems for fun... Their systems work just fine right now, thank you very much. Restrict the flow of value so that it only travels towards RDF-based systems and we're not going to get anywhere any time soon. Find ways for existing systems to benefit from RDF information and we're in a much better position for success. > I have come to think that a much more important task than setting a canonical > RDF/XML interchange format is developing a specification for translating RDF > models to user-defined XML formats, and vice versa. After all, I think > mappings from XML formats in general use is the realistic future of RDF. I am in 110% agreement with you on this point. It would be valuable for a standards body or perhaps just an open group of interested parties to establish a common set of expected behaviour for those applications which, to be frank, have real-world requirements for which the specifications cannot account or which the specifications counter. At least those systems which must go above and beyond the specifications could then do so with a certain degree of consistency. Jeremy Gray
Received on Sunday, 9 June 2002 17:45:15 UTC