- From: Michael Hausenblas <michael.hausenblas@deri.org>
- Date: Thu, 11 Aug 2011 17:41:09 +0100
- To: Souripriya Das <souripriya.das@oracle.com>, Ivan Herman <ivan@w3.org>
- Cc: ashok.malhotra@oracle.com, public-rdb2rdf-wg@w3.org
> 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? 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 16:41:38 UTC