- From: Alex Miller <alexdmiller@yahoo.com>
- Date: Mon, 26 Jul 2010 20:59:42 -0700 (PDT)
- To: Juan Sequeda <juanfederico@gmail.com>
- Cc: Richard Cyganiak <richard@cyganiak.de>, public-rdb2rdf-wg@w3.org
- Message-ID: <843358.99360.qm@web32504.mail.mud.yahoo.com>
Here are some slides to refer to - not sure how closely we'll adhere to them. http://www.slideshare.net/alexmiller/revelytix-rdb2rdf Alex ________________________________ From: Alex Miller <alexdmiller@yahoo.com> To: Juan Sequeda <juanfederico@gmail.com> Cc: Richard Cyganiak <richard@cyganiak.de>; public-rdb2rdf-wg@w3.org Sent: Mon, July 26, 2010 9:31:29 PM Subject: Re: D2RQ and Revelytix semantics I had a few more minutes to look closely at the examples and I think there are some misunderstandings... Case 0 and 1 look ok. On Case 2, you could do something as listed, although I think it might be a little weird. That example would not define any of the Department class triples ( http://.../dept#Dept/whatever a ex:Department ), so it is not equivalent to the D2RQ example. I think an equivalent to the D2RQ example there would be: :CourseCM a map:ClassMap map:source db:Course; map:subjectString “http://.../course#Course "; map:class ex:Course :DeptCM a map:ClassMap map:source db:Department; map:subjectString “http://.../ dept#Dept<Dept.d_id>"; map:class ex:Department :CourseDeptPM a map:PropertyMap; map:propertyOf :CourseCM; map:criteriaString “<Course.d_id> = <Dept.d_id>” map:predicate ex:given_at map:resourceValueString “http://.../dept#Dept ". although this is a good example of a case where a FK-PK relationship is likely already defined in the database and implies the Course.d_id = Dept.d_id. Here, we'd really like to a) avoid re-stating that join criteria and b) avoid repeating the uri pattern string in both DeptCM and CourseDeptPM. So I would really say that this is the expected equivalent example in our mapping language: :CourseCM a map:ClassMap map:source db:Course; map:subjectString “http://.../course#Course "; map:class ex:Course :DeptPattern a map:Pattern map:pattern “http://.../dept#Dept "; :DeptCM a map:ClassMap map:source db:Department; map:subject :DeptPattern; map:class ex:Department :CourseDeptPM a map:PropertyMap; map:propertyOf :CourseCM; map:predicate ex:given_at map:resourceValue db:CourseDeptForeignKey At the end, the foreign key reference is used to auto-generate the necessary join criteria and then walk from ForeignKey to associate PrimaryKey and back to a ClassMap mapping the PK columns, then use those column equivalences to create an equivalent pattern for the FK. That's a big leap though (esp as there are some ambiguous steps). We've walked through a lot of alternatives and while this kind of works, we're still thinking about better ways to do it. The goals of a and b above are still the important ones. In Case 3, the options there seem a little muddled from the alternatives in my mapping doc (in section 4.1.3) and in comparison to D2RQ. I would say that the closest equivalent to your D2RQ example would actually be something similar to what you had as option 2: :CourseClassMap a map:ClassMap; map:subjectString "http://.../course#Course "; map:source db:Course; map:class ex:Course; :StudentClassMap a map:ClassMap; map:subjectString "http://.../student#Student "; map:source db:Student; map:class ex:Student; :StudentCoursePM a map:PropertyMap; map:propertyOf :StudentClassMap; map:predicate ex:enrolled; map:source db:enrolled; map:join db:enrolled_StudentFK; map:resourceValue db:enrolled_CourseFK I don't understand your comment on this option as option 2 - it seems very similar to the D2RQ example you give. I actually thought the D2RQ example would include a uriPattern in map:StudentCourse based on the mappings I'd seen from our ontologists. However, in going through the D2RQ spec again, it seems your example is sufficient to pick up the foreign key uri pattern through the join. That actually addresses one issue that I had with our D2RQ examples! For the new option 2, I would use something similar to what you had for option 3 where instead of joining the join table into one of the base class maps, you would instead define a new ClassMap for the join table itself, but produce no triples from it (merely use it as a query context): :CourseClassMap a map:ClassMap; map:subjectString "http://.../course#Course "; map:source db:Course; map:class ex:Course; :StudentClassMap a map:ClassMap; map:subjectString "http://.../student#Student "; map:source db:Student; map:class ex:Student; :EnrolledClassMap a map:ClassMap; map:source db:enrolled; :enrolledPM a map:PropertyMap; map:propertyOf map:EnrolledClassMap; map:subject db:Enrolled_StudentFK; map:predicate ex:enrolled; map:resourceValue db:Enrolled_CourseFK; And option 3 should be what you had as option 1 which is just a simplification of the new option 2: :CourseClassMap a map:ClassMap; map:subjectString "http://.../course#Course "; map:source db:Course; map:class ex:Course; :StudentClassMap a map:ClassMap; map:subjectString "http://.../student#Student "; map:source db:Student; map:class ex:Student; :enrolledPM a map:PropertyMap; map:source db:enrolled; map:subject db:Enrolled_StudentFK; map:predicate ex:enrolled; map:resourceValue db:Enrolled_CourseFK; This option just merges the ClassMap that defines the context into the enrolledPM directly. Because any ClassMap or PropertyMap can construct a source of tuples, this is equivalent to the prior. Case 4: I don't understand what this example is supposed to do, or what it actually does in the D2RQ example. IF the idea is to create triples with predicate ex:student_at and resource object of the department, only when the student is taking a CS course, I think you would want something like this in our language: :StudentCM a map:ClassMap map:source db:Student; map:subjectString “http://.../student#Student "; map:class ex:Student. :DeptCM a map:ClassMap map:source db:Dept; map:subjectString “http://.../dept#Dept "; map:class ex:Department. :StudentCSDept a map:PropertyMap; map:propertyOf :StudentCM map:predicate ex:student_at; map:source db:Enrolled; map:source db:Course; map:source db:Dept; map:join “((<student> join <enrolled> on <student.s_id> = <enrolled.s_id>) join <course> on <enrolled.c_id> = <course.c_id>) join <dept> on <course.d_id> = <dept.d_id>” map:criteriaString “<Dept.title> = ‘CS’ “; map:resourceValueString “http://.../dept#Dept ". I'm also not sure what you meant regarding the Revelytix language doing things for the sake of query optimization? Hope that helps!! Alex ________________________________ From: Juan Sequeda <juanfederico@gmail.com> To: Alex Miller <alexdmiller@yahoo.com> Cc: Richard Cyganiak <richard@cyganiak.de>; public-rdb2rdf-wg@w3.org Sent: Mon, July 26, 2010 4:37:26 PM Subject: Re: D2RQ and Revelytix semantics Alex, Thanks for you comments. The objective is to classify everything (class types, data type property, object type property, user-generated rule/queries). I think this covers it all. Is there anything that I have wrong or I have understood incorrectly? After putting some thought into this, I believe existing languages such as D2RQ and Revelytix have the semantics of Database-Instance-and-Schema mapping while the Triplify approach has the semantics of Database-Instance-Only and uses SQL as the mapping language. Juan Sequeda +1-575-SEQ-UEDA www.juansequeda.com On Mon, Jul 26, 2010 at 4:05 PM, Alex Miller <alexdmiller@yahoo.com> wrote: Thanks! I think this is largely correct. I was working on simple examples myself but you've done a lot more than I have. :) > > > > > ________________________________ From: Juan Sequeda <juanfederico@gmail.com> >To: Richard Cyganiak <richard@cyganiak.de>; Alex Miller <alexdmiller@yahoo.com>; >public-rdb2rdf-wg@w3.org >Sent: Mon, July 26, 2010 3:51:24 PM >Subject: D2RQ and Revelytix semantics > > >Hi Richard, Alex and all > > >I took the liberty of analyzing D2RQ and Revelytix mapping language and compare >it to the semantics that Marcelo and I have defined in Datalog [1]. (BTW, >Marcelo defined the semantics of Datalog in the wiki also!) > > >Marcelo and I are still working on this so you can see a draft of what we are >doing in the following google doc (once we are done, we will put it on the >wiki.... tables in the wiki are a pain!) > > >https://docs.google.com/document/pub?id=1APTqD2lJLRjwV6gmPKqDRqC3aT8bozHF0udIXndMNWQ > > > >Please forgive me if I butchered the mapping language. > > >Quick conclusion: > > >- Both mapping languages are very similar >- Both mapping languages have the semantics established as >Database-Instance-and-Schema Mapping [1] (there is a definition of Classes and >Properties). There is no way to formally prove this because both languages don't >have existing defined semantics (right?) >- Revelytix language has different ways of saying the same thing for sake of >query optimization ( right?). (I personally believe this is something we should >avoid. Language and implementation details should be separate... just look at >SQL) > > >Looking forward to Alex's presentation tomorrow! > > > > >[1] http://www.w3.org/2001/sw/rdb2rdf/wiki/Database-Instance-Only_and_Database-Instances-and-Schema_Mapping > > >Juan Sequeda >+1-575-SEQ-UEDA >www.juansequeda.com >
Received on Tuesday, 27 July 2010 04:00:16 UTC