Re: Comments on Requirements and Usecase Document

Hi Everbody,

What is the process if for example Ashok recommends changing/dropping something, and somebody else disagrees with that? How are we going to avoid going back and forth between this. Honestly, I do not agree with several things that Ashok suggests. Here I go, being as precise as possible (I will be sending another email with my precise suggestions of changes):

- Why drop 1.1. and 1.2? Don't we need a motivation? This has been on the document for more than 1 month and nobody else has suggested to drop it. I recommend that this should stay because we need to have a motivation.
- This is a working draft, so instead of dropping the glossary in 1.4, I would add more terms and leave the definitions blank for now. This will show the whole world that 1) we know that there are specific terms that we need to define and 2) we are on our way to define them
- 2. Use Cases: Ashok suggests to change this completely into two different classifications (which actually seem to be four: map to sql schema derived ontology, map to domain ontology, materialize RDF and store and finally virtual mapping to allow SPARQL2SQL). These are requirements. I suggest to leave this section as-is. My reason is that somebody who will read this document will be attracted to one or maybe even all of these possibilities. For example, a company may be interested in just the possibility of using RDB2RDF because they want to integrate their RDBs. 
- At the end of UC1, Ashok recommends to add a new requirements
·       Mapping column names to RDF property names e.g. in 2.1.4 DaysToTake is mapped to hl7:durationInDays

  if we add this requirement, then shouldn't we also add that we should map a table name to a RDFS/OWL class? There is an MANY-to-MANY requirement where essentially we are mapping a table to a property also. 

- UC2: I believe that Ashok's suggestions are wrong. The wordpress example is not mapping to a RDF Schema derived from the Relational Schema.The use-case says "a mapping should be able to reuse existing vocabularies" If I'm not wrong, this use-case maps to SIOC, DublinCore, FOAF. Furthermore, where does it state that this use-case is for ETL? This use-case uses Triplfy which actually creates a virtual RDF graph. 

BTW, all of the use-cases could support ETL if needed, right? I do not see one specific use-case that is just for ETL. 

- Section 3, Approaches. I would like to know who thinks this needs to be removed. As I have mentioned before, I created these images so we could internally get on the same page. I wasn't expecting this to get into the doc. However, seeing this now in the document, I believe adds context in how the mappings can generated. 

This is what I have up to now. I will be sending another email will all my precise suggested changes.

Cheers



On May 19, 2010, at 5:44 PM, ashok malhotra wrote:

> See attached Word file.
> -- 
> All the best, Ashok
> <Requirements and UseCases.doc>