Re: ISSUE-41 What are the options?

On Wed, 2011-05-18 at 06:13 -0700, ashok malhotra wrote:
> Reading the extensive discussion on ISSUE-41, there seem to be three options on
> how to handle SQL NULLs in the database:
> 
> A)  Do not generate triples for NULLs
> B)  Define a special values such as RDB2RDF:NULL to represent a NULL
> c)  Use a blank node to represent a NULL
> 
> As Souri pointed out on the call and Juan in mail, option A) does not lose information
> as long as you have a RDF Schema.  Alexandre points out that DM does implicitly
> define a RDF Schema and I think R2R also, implicitly, defines a RDF Schema.  So, I
> would argue that A) does not lose information.
> 
> The problem with B) is that it defines a new "value" and the SQL NULL is not really
> a "value".  It has special semantics such as "NULLs cannot be joined with each other."
> Richard has pointed out other problems with translating NULL to a special value.
> 
> Re. C) I confess I do not understand bNodes very well.  The RDF documents refer to them
> as existential variables which seems just different from a representation for SQL NULLs.
> 
> Does this makes sense?  Are there other options?

Yes: generating a description of the schema from the RDB instance, which
Juan actually mentioned in his first email, but it seems that people
didn't follow him up. This is actually very easy to do as soon as we
have an ontology for that, and we decided (informally) that this would
be postponed until we got the data mapping finalized, which is more
difficult.

And this doesn't have to be called Information Preserving anyway, this
is just part of the Direct Mapping. What was introduced as a problem is
not a problem for me, at least for the Direct Mapping. I don't think it
makes any sense in the case of R2RML, as obfuscation is obviously
needed.

Alexandre.

Received on Wednesday, 18 May 2011 13:29:11 UTC