- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 11 Aug 2011 19:57:39 +0200
- To: Michael Hausenblas <michael.hausenblas@deri.org>
- Cc: Souripriya Das <souripriya.das@oracle.com>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, "public-rdb2rdf-wg@w3.org" <public-rdb2rdf-wg@w3.org>
On 11 Aug 2011, at 18:41, Michael Hausenblas <michael.hausenblas@deri.org> wrote: > >> Richard's proposal helps, but does not resolve the issue. >> However, we will not block the LC for this. >> So, we can mark the issue as resolved based on the new proposal, with the non-blocking objection from Oracle recorded. > > Thanks for this, it will help keeping the 1 Sep deadline. Though I'm puzzled what you mean with a 'non-blocking objection' AFAIK, there is nothing like this process-wise. Even a formal objection is only possible post-LC IIRC. > Ivan? > Indeed. The process knows only the term of a formal objection: http://www.w3.org/2005/10/Process-20051014/policies.html#FormalObjection This means that this issue will have to be handled by the director (formally Tim, in practice the domain leaders who play his role) and he will have to make a decision. Ie, there is no such thing as a non-blocking formal objection... Ivan > Cheers, > Michael > -- > Dr. Michael Hausenblas, Research Fellow > LiDRC - Linked Data Research Centre > DERI - Digital Enterprise Research Institute > NUIG - National University of Ireland, Galway > Ireland, Europe > Tel. +353 91 495730 > http://linkeddata.deri.ie/ > http://sw-app.org/about.html > > On 11 Aug 2011, at 17:29, Souripriya Das wrote: > >> Ashok, >> >> Richard's proposal helps, but does not resolve the issue. >> However, we will not block the LC for this. >> So, we can mark the issue as resolved based on the new proposal, with the non-blocking objection from Oracle recorded. >> >> Thanks, >> - Souri. >> >> ashok malhotra wrote: >>> >>> Souri: >>> I'm not sure what you are proposing. >>> Should the issue be resolved with Richard's latest version? >>> If you have an objection when will that be resolved? Do >>> you intend to bring this up as a Last Call comment? >>> All the best, Ashok >>> >>> On 8/11/2011 8:51 AM, Souripriya Das wrote: >>>> >>>> Richard, >>>> >>>> Thanks for working on it. This proposal is better than the text we had earlier. >>>> So, again, let us just record the objection from Oracle, incorporate the text you have proposed below, and proceed towards our LC goal. >>>> >>>> Thanks, >>>> - Souri. >>>> >>>> Richard Cyganiak wrote: >>>>> >>>>> Souri, >>>>> >>>>> I mulled it over a bit more. A proposal below. Summary: require that R2RML mapping *documents* are in Turtle, but don't say *anything* about syntax for R2RML *processors*. >>>>> >>>>> In detail: >>>>> >>>>> 1. Delete the following text: >>>>> >>>>> [[ >>>>> A conforming R2RML processor must accept R2RML mapping documents in Turtle syntax. It may accept R2RML mapping graphs encoded in other RDF syntaxes. >>>>> ]] >>>>> >>>>> 2. In the following text, change “R2RML mapping” to “R2RML mapping graph”: >>>>> >>>>> [[ >>>>> An R2RML processor is a system that, given an R2RML mapping and an input database, provides access to the output dataset. >>>>> ]] >>>>> >>>>> This would be acceptable to me as long as the definition of “R2RML mapping document” remains unchanged: >>>>> >>>>> [[ >>>>> An R2RML mapping document is any document written in the Turtle [TURTLE] RDF syntax that encodes an R2RML mapping graph. >>>>> ]] >>>>> >>>>> Rationale: >>>>> >>>>> Making the Turtle syntax mandatory for “R2RML mapping documents” should be sufficient to ensure that the ecosystem (tutorials, books, editors, etc) centers itself firmly around Turtle. >>>>> >>>>> For implementers of R2RML processors, it is then in their best interest to support Turtle. >>>>> >>>>> Implementers who are unwilling to do so for whatever reason could still claim conformance. That's a bit paradoxical, as users will first have to convert a conforming R2RML mapping document to the supported syntax using a third-party tool before they can actually use it; but it might be a workable compromise. >>>>> >>>>> (Tangential side note: N-Triples is a subset of Turtle; so when you convert a conforming R2RML document to N-Triples, it is actually *still* a conforming R2RML document. Although not a very readable one.) >>>>> >>>>> Best, >>>>> Richard >>>>> >>>>> >>>>> On 10 Aug 2011, at 22:23, Richard Cyganiak wrote: >>>>> >>>>> >>>>>> On 10 Aug 2011, at 21:00, Souripriya Das wrote: >>>>>> >>>>>>> The benefit of Independence or modular organization is that it allows combining things >>>>>>> >>>>>> I do understand this advantage. But the advantage of increased interoperability that is brought by a standard syntax clearly outweighs the advantage of modularity, in my opinion. >>>>>> >>>>>> >>>>>>> However, if an implementation can consume only N-Triple, an R2RML mapping specified in Turtle may first have to be translated (using say Raptor [1]) into N-Triples format. So it appears that such an implementation would then be considered non-conformant because it does not directly consume R2RML mapping(s) presented in Turtle format. >>>>>>> >>>>>> Correct. >>>>>> >>>>>> >>>>>>> But, for all practical purposes, this implementation is perfectly usable with R2RML vocabulary. >>>>>>> >>>>>> No it isn't. An implementation that only understands N-Triples cannot consume an R2RML example that is written in a book. It cannot consume an R2RML file that is emitted by a visual R2RML editor. I do not see why such an implementation should be allowed to claim compatibility with that book or that visual mapping editor. >>>>>> >>>>>> You can bundle it with Raptor to make it conforming. >>>>>> >>>>>> Best, >>>>>> Richard >>>>>> >>>>> >>>>> >>>>> >
Received on Thursday, 11 August 2011 17:54:35 UTC