Comments needed – Re: Lookup table proposal (re ISSUE-72)

On 10 Dec 2011, at 13:53, David McNeil wrote:
> [
> PROPOSAL: Resolve ISSUE-72 by removing the lookup table facility from the R2RML spec.
> ]

I think there's consensus that this feature is important. The task of mapping between one set of codes and another set of codes is common in data integration. Actually I believe it's so essential that any vendor is going to want to implement this anyway once they get feedback from actual users. We certainly won't ship R2RML support in D2RQ without this, even if it means a proprietary extension; otherwise R2RML would be a step backwards compared to the D2RQ mapping language. Other implementers would likely do the same and end up with different proprietary extensions. Not putting it in the standard right away *in some form* would be a failure on the part of the WG, IMO.

The reason why we don't have translation tables in the R2RML draft right now is rather silly. The disagreement is this:

A) I think we did it wrong in D2RQ seven years ago, and I want to do it right this time by using a standard – SKOS.

B) Souri dislikes SKOS for reasons not known to me, and prefers something proprietary but tailored to the R2RML use case.

C) The rest of the WG appears to have no opinion (notable exception: Ted), leaving Souri and me at an impasse.

All the other concerns and objections that were brought up could be easily resolved if that big issue was settled.

1. “It requires another LC” – not necessarily, as Ivan said.

2. “SKOS looks complicated” – actually it's not, but to realize this one has to be willing to look at the spec.

3. “It can't deal with some contrived corner case” – it can be easily made to deal with that case if the WG feels that's important.

4. “It was introduced too shortly before LC” – six weeks should be enough even for busy WG members.

So, instead of just throwing the towel because Souri and me are stuck in an unproductive circular debate, maybe we can use the collective wisdom of this WG and get some more input on the core question – should we use the SKOS standard at the cost of more complexity and loss of flexibility, or should we taylor something optimised for R2RML at the cost of re-inventing this particular wheel?

Best,
Richard



> 
> -David
> 
> [1] - http://www.w3.org/2001/sw/rdb2rdf/track/issues/72

Received on Monday, 12 December 2011 19:44:02 UTC