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

All,


On Monday, December 12, 2011, Richard Cyganiak wrote:

> 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.
>

I agree with this. Otherwise, a user would only be generating custom URIs
and would not be able to reuse existing URIs.


>
> 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.
>

Souri, can you please be explicit on your reason for disliking SKOS. Is it
because it's more complicated? Or because this means that a mapping user
would have to learn yet another standard before they could use R2RML?


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

I will start to take part of this discussion. I do need to catch up on
Richard and Souri's proposal. But I do believe that Richard is right. If we
get R2RML out without this, people are going to want it and won't wait for
R2RML 1.1 and start creating their proprietary extension... and it would
defeat the purpose of the WG.


>
> 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.
>

I have never looked at SKOS to be honest because I don't have time
to thoroughly learn about *another* semantic web standard. If we are
tackling a semantic web audience that will most probably be familiar with
SKOS, then I think we are ok. But if you are tackling a non-semantic web
audience and the only reason they are learning R2RML is because their boss
told them to export their RDB data as RDF... besides the R2RML learning
curve... you are going to make them learn SKOS, assuming they "kinda" know
some RDF and SPARQL... this is going to be a pain. This is where all the
alphabet soup comes in and is not appealing (and this is my real world
experience).

However... if the SKOS aspect of the translation tables doesn't look to
difficult and for a non-semantic web user it still looks like R2RML
(because of the syntax), then I think it would work.

I would like to understand more about Souri's objections though in order to
fully support a side.


>
> 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.
>

What are these corner cases (and again.. sorry if this has been stated
before)

>
> 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
>
>
>