W3C home > Mailing lists > Public > public-rdb2rdf-wg@w3.org > August 2011

Re: Please review: syntactic sugar and polishing (ISSUE-54, ISSUE-56, ISSUE-59, ISSUE-60)

From: Richard Cyganiak <richard@cyganiak.de>
Date: Tue, 30 Aug 2011 17:01:09 +0100
Cc: W3C RDB2RDF <public-rdb2rdf-wg@w3.org>
Message-Id: <11949109-ECAB-4CF4-A126-1057ED6C58AB@cyganiak.de>
To: David McNeil <dmcneil@revelytix.com>
Hi David,

Thanks a lot for the comments.

On 30 Aug 2011, at 16:37, David McNeil wrote:
> There are trade-offs to offering syntactic sugar, I would like the group to consciously consider the trade-offs and take a position. I think the core tradeoff is a simple spec, with a single way to perform a task, vs a "sugared" spec with more wrinkles but more concise for common cases. There are implementation and education costs to these wrinkles. 

I agree that there is a trade-off.

> Personally, I think it makes sense to avoid the sugar in 1.0 of the spec, but if the consensus is towards sugar in 1.0 then I could go along with that.


I note that we have three instances of syntactic sugar.

>> ISSUE-54: Simpler constant-valued term maps
>> http://www.w3.org/2001/sw/rdb2rdf/track/issues/54
>> 
>> Instead of this:
>> 
>>    [] rr:predicateMap [ rr:predicate ex:foo ].
>> 
>> you now have to write one of these two forms:
>> 
>>    [] rr:predicateMap [ rr:constant ex:foo ].
>>    [] rr:predicate ex:foo.
>> 
> 
> I think this is a good change (assuming we want a sugared spec) because constant predicates seem to be the norm for the use cases I have seen. 

One option here is to forbid the long form with rr:constant. AFAICT there's no benefit in allowing the long form for constant-valued term maps. (Column- and template-valued term maps of course need the long form with intermediate node because they can take additional properties such as datatype, language etc, but none of these additional properties are allowed on constant-valued term maps, if I'm not mistaken.)

So we could *always* get the compact form without having two ways of saying the same thing. (I believe this would be a better design, and would leave us with two forms of syntactic sugar.)

>> ISSUE-56: Default termType for template-valued term maps should be IRI
>> http://www.w3.org/2001/sw/rdb2rdf/track/issues/56
>> 
> 
> This makes sense to me.  
> 
>> The default term type is now always rr:IRI, except for rr:column in an object map.
> 
> I need to think this through more. Seems this is a bit different than ISSUE-56? 

Before ISSUE-56 change:

  rr:IRI is default type for subject, predicate, graph maps
  rr:Literal is default type for object maps

The change was to make rr:IRI also the default for template-valued object maps. So we get:

  rr:Literal is default type for object maps that are not template-valued
  rr:IRI is default type for everything else

which is the same as what I said above.

>> ISSUE-59: Syntactic sugar for triples maps that only have a single predicate-object map
>> http://www.w3.org/2001/sw/rdb2rdf/track/issues/59
>> 
> 
> I am curious what use-case you have in mind for this. Seems to me that this is primarily useful for simple examples or getting started because I expect most mappings to involve multiple columns from a table. From that perspective this does not look like a useful change to me.

See here:
http://www.w3.org/2001/sw/rdb2rdf/r2rml/#example-m2m

The motivating use case is many-to-many tables, which AFAICT typically will be modelled as a separate triples map with just a single p-o map.

I think this will be fairly common, so having a short way of saying it is quite a plus.

>> ISSUE-60: Syntactic sugar for the simple case of logical tables
>> http://www.w3.org/2001/sw/rdb2rdf/track/issues/60
>> 
>> Instead of this:
>> 
>>    <#TriplesMap1> rr:logicalTable [ rr:tableName "EMP" ].
>> 
>> you can now also write this equivalent form:
>> 
>>    <#TriplesMap1> rr:tableName "EMP".
>> 
> 
> I think this is a good change (assuming we want a sugared spec).

Ok

Best,
Richard
Received on Tuesday, 30 August 2011 16:01:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 30 August 2011 16:01:40 GMT