Re: A Direct Mapping of Relational Data to RDF is FPWD

* Alexandre Bertails <bertails@w3.org> [2010-11-18 16:06-0500]
> 
> 
> On Thu, 2010-11-18 at 11:53 -0800, Alex Miller wrote:
> > My first reaction was that it might be a bit over-rigorous in this
> > case:
> 
> First, thanks for the feedback.
> 
> I'll answer more specifically on the formalism, letting Eric answering
> about the more Semantic Web oriented questions.
> 
> > sealed abstract class SQLDatatype
> >   case class SQLInt () extends SQLDatatype
> >   case class SQLFloat () extends SQLDatatype
> >   … 
> > case class SQLString () extends SQLDatatype
> >  
> > Using a sealed class here says that this is the complete set of
> > possible data types.
> 
> We just find easier to rely on exhaustive pattern matching during spec
> development. It's an implementation detail.

We're leaning on the compiler to make sure that every SQL datatype
maps to some RDF literal datatype. We could do this another way by
giving an abstract sql.Datatype an empty toXSDtype:rdf.IRI method.

We got some feedback saying that we should use plain literals instead
of xsd:string typed literals. In this case we'd need something more
like toRdfNode:rdf.Node.

> > That seems like painting yourself in a pretty small box when it comes
> > to the richness of data types found in dbs in practice.
> 
> The real question is: do we want to model *any* vendor's type? Or only
> the ones from the SQL specification?
> 
> And don't worry, this is a First Public Working Draft. Things can change
> a lot before it becomes a Recommendation. By giving your feedback (and
> participating to the Working Group), you have an opportunity to
> influence our work.
> 
> > FYI, Revelytix is actually using Clojure for our implementation
> > (although we considered Scala closely too).  
> 
> Nice! It will also be easy for you to implement the Direct Mapping, or
> just works on ours :-)
> 
> 
> > Some other comments:
> > 
> > 
> > 1) I saw the requests for explanation of the #_ row IRIs on the list
> > but I don't recall ever seeing the answer.  Easily could have been in
> > the minutes that I didn't read though. :)   I saw the hash-vs-slash
> > note in the spec but is the trailing _ just to have something after
> > the #?

I don't think this conversation with Richard ever finished. The main
motivation is that GETs on database row IRI's return a resource which
usefully describes that item in the database and that the row IRI has
an identifier distinct from the resource describing it. This spec took
a hash approach so folks wouldn't need to involve a 303 dance.

> > 2) I was surprised at a first glance to see ,'s in the compound key
> > IRIs but it's equivalent to the same information we're using in our
> > subject IRIs.  

We're all ears about punctuation. Got a preferred separator?

> > 3) We were not smart enough to use blank nodes for tables w/o primary
> > keys and just punted on the issue but I think the blank node solution
> > works well.

Yeah, this is crucial when you either have no candidate key promoted
to primary key, your primary key was projected away (direct graph for
a view), or don't want to advertise identifiers (warehouse which
updates every night and ends up with different row numbers). I think
the blank node semantics match perfectly the concepts motivating SQL
to work over multisets.

> > 4) We went back and forth on what to do when having multiple unique
> > keys in a table and whether to create multiple "same as" identifiers
> > in that case to the primary key subject IRI.  You're consistently
> > using the PK subject IRI which I think is the right choice for the
> > direct mapping.  I haven't looked at R2RML enough yet to understand
> > the range of choices there.

Yeah, want to be sure that a reference arc points to something which
is the subject of the appropriate arcs. For rigor's sake, I looked at
making assertions about all of the candidate keys, but then useful
cardinality between SPARQL and SQL queries was impossible.

> > 5) Issue (formalism-model) refers to sections 5 and 6 but those should
> > be 3 and 4.  Personally, I find the definition to be easier to read
> > than the rules, but that's probably due to familiarity. 
> 
> Some last minute edit made the reference inconsistent. The W3C Webmaster
> has already been slapped for inattentiveness.

and the editor.

> > 6) It would be really nice to see an equivalent R2RML that produces
> > the direct mapping.
> 
> Actually, one of the applications of the Direct Mapping is to serve as a
> default mapping for R2RML, when you give an empty configuration.
> 
> Alexandre.
> 
> > 
> > 
> > ______________________________________________________________________
> > From: Alexandre Bertails <bertails@w3.org>
> > To: Eric Prud'hommeaux <eric@w3.org>
> > Cc: Alex Miller <alexdmiller@yahoo.com>; Michael Hausenblas
> > <michael.hausenblas@deri.org>; RDB2RDF WG <public-rdb2rdf-wg@w3.org>
> > Sent: Thu, November 18, 2010 12:53:14 PM
> > Subject: Re: A Direct Mapping of Relational Data to RDF is FPWD
> > 
> > On Thu, 2010-11-18 at 12:43 -0500, Eric Prud'hommeaux wrote:
> > > * Alex Miller <alexdmiller@yahoo.com> [2010-11-18 08:26-0800]
> > > > Looks great all.  I've just skimmed through it but it's
> > interesting seeing how 
> > > > you've handled certain issues in similar and different ways from
> > what we've done 
> > > > at Revelytix. 
> > > > 
> > > > We are interested in supporting these specs moving forward
> > although I'm not sure 
> > > > yet when we'll start working on it.  If things move along
> > favorably we may also 
> > > > be able to open source the implementation at some point.
> > > > 
> > > > I was surprised (and delighted) to see the Scala syntax in the
> > spec too. :)  
> > > 
> > > It's perhaps over-rigorous for the purposes of presentation (uses
> > case
> > > classes rather than type= to ensure type safety). The source:
> > >
> > https://dvcs.w3.org/hg/FeDeRate/file/tip/directmapping/src/main/scala/DirectMapping.scala
> > 
> > Case classes are the Scala algebraic datatype implementation. They
> > define both types (the classes) and type injectors (the constructors).
> > 
> > Sure, we should split the formal definition from the type-safety
> > proof.
> > 
> > Pattern matching + type-checking is not "over-rigorous" when you gain
> > such confidence in your formalism.
> > 
> > Alexandre.
> > 
> > > 
> > > is editable by RDB2RDF members.
> > > 
> > > > ________________________________
> > > > From: Michael Hausenblas <michael.hausenblas@deri.org>
> > > > To: RDB2RDF WG <public-rdb2rdf-wg@w3.org>
> > > > Sent: Thu, November 18, 2010 10:06:29 AM
> > > > Subject: A Direct Mapping of Relational Data to RDF is FPWD
> > > > 
> > > > 
> > > > All,
> > > > 
> > > > Congrats to the team, esp. a big thanks to the editors - "A Direct
> > Mapping
> > > > of Relational Data to RDF" [1] is now published as FPWD.
> > > > 
> > > > Cheers,
> > > >      Michael
> > > > 
> > > > [1] http://www.w3.org/TR/rdb-direct-mapping/
> > > > 
> > > > -- 
> > > > Dr. Michael Hausenblas, Research Fellow
> > > > LiDRC - Linked Data Research Centre
> > > > DERI - Digital Enterprise Research Institute
> > > > NUIG - National University of Ireland, Galway
> > > > Ireland, Europe
> > > > Tel. +353 91 495730
> > > > http://linkeddata.deri.ie/
> > > > http://sw-app.org/about.html
> > > 
> > 
> > 
> > 
> > 
> 
> 

-- 
-ericP

Received on Thursday, 18 November 2010 21:45:28 UTC