- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Fri, 12 Sep 2008 20:44:16 +0100
- To: "Alan Ruttenberg" <alanruttenberg@gmail.com>
- Cc: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, public-owl-wg@w3.org
On Sep 12, 2008, at 6:35 PM, Alan Ruttenberg wrote: > On Fri, Sep 12, 2008 at 12:42 PM, Bijan Parsia > <bparsia@cs.man.ac.uk> wrote: >> Just for clarity, what is the argument and what are the hinge points? > > That a solution to this issue should not work for only one > serialization of RDF, i.e. it should be independent of the specific > RDF serialization. That's not an argument. That is a proposed requirement. That requirement has been shown to be, in one sense, incoherent. There is *no* solution which is independent of the specific RDF serialization. If we define a bespoke solution, *all* serializations will have to be updated. So it's an impossible requirement (unless, for example, we want to take control of *all* the RDF serializations in the work, Trix, ntriples, turtle, TRIPLE, etc.). Thus, we don't need to meet it. If we repair it a bit i.e., to something which is *able* to cross serializations, then, as I've already pointed out, XInclude does the job (since other serialization can easily make their own syntax for this feature). Thus, your requirement is met by the XInclude proposal. Of course, there are strong considerations against a bespoke solution, including reuse of existing standards, not complicating our spec with a bespoke solution esp. at this late stage, etc. etc. I've not seen you address any of these yet, though, of course, there's little point unless you come up with a criticism. Presumably, if we have two solutions and one is one we make up and one is an existing standard explicitly designed for this problem, we should reuse the existing standard (esp. when, contrary to your speculation, it is widely implemented and deployed). Cheers, Bijan.
Received on Friday, 12 September 2008 19:45:01 UTC