Re: Review of R2RML working draft

Am 25.07.2011 15:04, schrieb Richard Cyganiak:
>> 2.3 A Mapping for the Example Database
>>
>> * it is unclear what is actually meant here with "rr:parentTriplesMap
>> <#TriplesMap2>;" and how this referencing works - we should add few more
>> sentences as explanation here
> 
> I see what you mean. If a reader knows Turtle, then this will make sense to them; if they don't know Turtle, then it will be rather confusing. We state in the Introduction: “A reader's familiarity with … the Turtle syntax is assumed.” But there is a valid question here whether we're setting the bar too high.


What I mean is not related to the Turtle syntax. While the example is
quite intuitive in general the part with "rr:parentTriplesMap" is not.
What does this property actually mean here? Can we add a brief
conceptual explanation?

>> "An R2RML mapping document is any document written in the Turtle RDF
>> syntax that encodes an R2RML mapping graph."
>>
>> I guess this was discussed already during the telco, but do we really
>> require a mapping to be in the Turtle syntax - what's the purpose of
>> using RDF then - from my POV all valid RDF serializations should be
>> eligible.
> 
> All RDF serializations *are* eligible. You can encode an R2RML mapping graph in any syntax you like, and it's still a conforming R2RML mapping graph. (It may just not be a conforming R2RML mapping *document*, which is a different concept and a stronger claim.)

To be honest, this is quite confusing and from my POV introducing the
term mapping document is not required (see below).

> See here for the argument why *just* defining R2RML as a graph, without talking about syntax, would be a Bad Thing:
> http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Jun/0165.html
> 
> In summary, our goal is interoperability, and for interoperability you need to exchange actual files, and files need to be in a syntax, and if two implementations don't talk the same syntax then they don't interoperate.
> 
>> When reading a little further there is even a contradiction with the
>> following sentence:
>>
>> "A conforming R2RML processor MUST accept R2RML mapping documents in
>> Turtle syntax. It MAY accept R2RML mapping graphs encoded in other RDF
>> syntaxes."
> 
> Where do you see a contradiction?

Ok, with the distinction between mapping document and mapping graphs it
might not be a contradiction, but this is quite confusing to the reader.
I would omit this distinction (and remove the term mapping document
altogether) and just write "A conforming R2RML processor MUST accept an
R2RML mapping graph serialized in Turtle syntax."

>> * I would not introduce a new term "SQL query-based table" here, since
>> it is nothing else than an SQL query -- why not just writing "SQL query"
>> instead and confuse the reader less. After all we just emulate the
>> creation of views here in R2RML, in order to not require the privilege
>> for the creation of real views.
> 
> The way I think about this, as "SQL query" is the string that goes into the rr:sqlQuery property. A "SQL query-based table" is one kind of R2RML logical table, and it is a resource that has multiple properties, including rr:sqlQuery and rr:sqlVersion. I think it would be more confusing (and hard to maintain from a precise specification point of view) to use the same term for both.
> 
> Ultimately, the term "SQL query-based table" just exists in order to disambiguate between "SQL query" as understood in a SQL context ("SELECT ... FROM ...") and "SQL query" as understood in an R2RML context (the value of rr:logicalTable, which has a rr:sqlQuery property that contains a "SELECT ... FROM ..." string).
> 
> You will find in later sections that the spec often introduces such terms, which are not terribly useful from a didactic point of view, in order to be precise and unambiguous.
> 
> Might replacing "SQL query-based table" with another term ("Logical SQL query", "R2RML View", whatever) help?

"R2RML View" would be actually a nice term for that, since this is what
it actually is a workaround for not being able (or requiring the
privilege) to create real views. On the other hand as you mentioned
below the analogy with SQL views is not completely correct. Maybe a
topic for a brief discussion during the telco.

Anyway thanks for doing all the other fixes and the great editing work
in general. As said earlier I will continue with my review later this week.

Best,

Sören

Received on Monday, 25 July 2011 13:31:38 UTC