Re: Requirements: tooling & named graphs

On 3/12/2010 5:33 AM, Ivan Mikhailov wrote:
> Hello Lee,

Hi Ivan,

Thanks for the response! Comments below...

>> Cambridge Semantics plans to implement the RDB2RDF standards in our Anzo
>> software... we've identified 2.5 requirements for the
>> RDB2RDF mapping language:
>>
>> 1/ Tooling
>>
>> It must be straightforward to create tooling that generates mappings.
>> Most of the candidate designs I've seen have no problem here, but I
>> wanted to include it anyway. Declarative XML- or RDF-based mappings are
>> very easy to target. Mappings based on less structured query forms (SQL
>> views or SPARQL CONSTRUCT queries) are less desirable but are doable.
>>   From our perspective with respect to tooling, a SPARQL CONSTRUCT-based
>> approach is are preferable to a SQL DDL-based approach.
>
> CONSTRUCT approach does not provide enough information about mapping to
> SPARQL-to-SQL optimizing compiler. Efficient mapping requires much more
> details than CONSTRUCT may fit. It would be nice to use CONSTRUCT but
> we've made much more complicated language to not kill the performance.

Can you talk more about the requirements that you've identified for a 
mapping language for performance reasons that go beyond the expressivity 
of CONSTRUCT queries? Is there a write-up of this somewhere?

I don't have implementation experience here myself, but would definitely 
like to hear Eric P's take on this, as well.

>> 2/ Named Graphs
>>
>> The mapping language should be capable of mapping a relational schema
>> into SPARQL's named graph model. The granularity of the graphs should be
>> tweakable within the mapping -- for example, we sometimes will map an
>> entire table into a single graph, and other times we will map specific
>> rows/resources into their own graphs.
>
> We've found that mapping of graph does not differ much from mapping of
> other items of a quad. So I absolutely support this requirement.
>
>
>
>> ...and a half/ Update
>>
>> I realize that updating the relational database is beyond the scope of
>> our charter. That said, we would like to consider the potential
>> extensibility of the mapping approach chosen to handle (some cases of)
>> writing data back to a relational schema. (Either via SPARQL Update or
>> via triple/quad removes&  adds.
>>
>> (As we begin to compare and contrast design candidates, these are some
>> of the criteria that we'd like to use to evaluate the possibilities.)
>
> I've written http://esw.w3.org/topic/UpdatingRelationalDataViaSPARUL
> as a seed for a discussion but it did not cause any reaction so I
> postponed the implementation. I'd like to hear any comments/wishes, even
> strong reject is better than nothing.

Excellent & thanks - I'll take a look at that soon and send comments.

Lee

>
> Best Regards,
>
> Ivan Mikhailov
> OpenLink Software
> http://virtuoso.openlinksw.com
>
> P.S. This is my personal opinion, not a formal reply from any W3C
> working group.
>
>
>

Received on Friday, 12 March 2010 14:42:50 UTC