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):
>

Thanks! The process for is if Ahsok recommends changing dropping or
changing text and it's substantial (i.e. dropping 1.1 and 1.2) then it
should be discussed by the group. The judge of whether or not a change is
substantial is usually in the hands of the editor(s), but if a change is
judged as substantial by one of the members of the WG (as you have done
rather well in the e-mail below) then it should be discussed by the
editor. So if Michael does not bring these changes up tomorrow for
discussion, please step in and do so.

> - 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>
>
>

Received on Monday, 24 May 2010 14:55:06 UTC