Re: Final grammatical comments on use-case document

>
> Harry,
>
>> Here they are. Two substantial changes:
>
> I disagree with this approach out of principle. We've discussed and
> resolved
> all substantial changes during last telecon.
>

Of course, just noting that these two changes were the only ones that
seemed that really should be flagged for the editor's awareness, but as we
have consensus to publish of course the editor's discretion is fine with
me.


> That said, let's see what you have ... :)
>
>> 1)  The main comment I have is actually that I think R2ML may not be the
>> best name, so let's not use it in the document. The document suffers
>> from
>> confusion on this point, as sometimes the term R2ML is used, and other
>> terms R2RML is used. Therefore, let's just say "RDB2RDF mapping
>> language"
>> which is self-explanatory and not confusing for readers not in the WG.
>> So
>>
>> - s/R2ML/RDB2RDF mapping language
>> - s/R2RML/RDB2RDF mapping language
>
> No. R2RML is perfectly defined in our charter [1]. I agree we should use
> it
> consistently in the document, though, so:
>
> s/R2ML/R2RML
>

As long as we're consistent with R2RML!

>> 2) This MUST seems like it should be deleted or at least turned into a
>> MAY. My suggested rewording is below:
>>
>> 3.1.2.3
>> DELETE EDITORAL NOTE OR FIX
>
> I leave it up to Eric to fix this in the sense we've discussed it on last
> Tuesday's call.

+1. Again, noting that there was a dependency in the MUSTs that we seemed
to have missed in our call.

>
> Cheers,
>       Michael
>
> [1] http://www.w3.org/2009/08/rdb2rdf-charter
>
> --
> Dr. Michael Hausenblas
> 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
>
>
>
>> From: Harry Halpin <hhalpin@w3.org>
>> Date: Wed, 12 May 2010 19:35:57 +0100 (BST)
>> To: RDB2RDF WG <public-rdb2rdf-wg@w3.org>
>> Subject: Final grammatical comments on use-case document
>> Resent-From: RDB2RDF WG <public-rdb2rdf-wg@w3.org>
>> Resent-Date: Wed, 12 May 2010 18:36:00 +0000
>>
>> Here they are. Two substantial changes:
>>
>> 1)  The main comment I have is actually that I think R2ML may not be the
>> best name, so let's not use it in the document. The document suffers
>> from
>> confusion on this point, as sometimes the term R2ML is used, and other
>> terms R2RML is used. Therefore, let's just say "RDB2RDF mapping
>> language"
>> which is self-explanatory and not confusing for readers not in the WG.
>> So
>>
>> - s/R2ML/RDB2RDF mapping language
>> - s/R2RML/RDB2RDF mapping language
>>
>> 2) This MUST seems like it should be deleted or at least turned into a
>> MAY. My suggested rewording is below:
>>
>> 3.1.2.3
>> DELETE EDITORAL NOTE OR FIX
>>
>> - The R2RML language MUST enable transformation of SPARQL queries over
>> the
>> RDF view into efficient SQL queries over the relational database. -> The
>> RDB2RDF mapping language SHOULD allow the transformation of SPARQL
>> queries
>> over the RDF view into efficient SQL queries over the relational
>> database
>> without materializing the view.
>>
>> All are the rest are cosmetic grammatical changes, listed below:
>> ------------
>>
>>
>> 2.4 UC4
>>
>> - DELETE hyperlinked "rCAD - RNA Comparative Analysis using SQLServer:"
>>
>> - Put hyperlink here "implemented the RNA Comparative Analysis Database
>> -rCAD"
>>
>> - DELETE " The rCAD consists of different schema: Sequence Metadata,
>> Evolutionary Relationships, Structural Relationships and Sequence
>> Alignment." Sentence seems odd and out of place.
>>
>>
>> - Rob, from the RNA lab would -> Rob from the RNA lab would
>> DELETE COMMA
>>
>> - However MAO-> However, MAO
>> ADD COMMA
>>
>> - Throughout this use case, let's use the same background color as in
>> the
>> first use-case.
>>
>> -Therefore, Rob will like to map his rCAD database to the MAO ontology
>> ->
>> Therefore, Rob will like to map his rCAD database to the MAO ontology in
>> OWL DLThis is just part of the Multiple Alignment Ontology in OWL DL.
>>
>> 2.5 UC
>>
>> - to RDF / SPARQL -> to RDF so that it can be queried in SPARQL
>>
>> 2.6 UC
>>
>> - as different {{{rdf:type}}}s -> as different <code>rdf:type</code>s
>>
>> 3.1.1
>>
>>
>> -This composes a direct graph -> In RDF terminology, this composes a
>> direcxt graph (also called a "putative ontology" in database
>> terminology).
>>
>> - the relation database. -> the relational database.
>>
>> -  a (virtual) RDF graph ->  a (possibly virtual) RDF direct graph
>>
>> - There are many types of graph transformation, representable by SQL
>> views, SPARQL CONSTRUCTs, Horn logic, etc. The RDB2RDF workiing group
>> would like feedback to decide if, for instance, the transformations
>> expressed by RIF Basic Logic Dialect are appropriate. Use case
>> contributions to this document will help determine the exact
>> expressivity
>> required.-> There are many types of graph transformations, representable
>> by SQL views, SPARQL CONSTRUCTs, the RIF Basic Logic Dialect, etc. The
>> RDB2RDF workiing group would like feedback to decide, particularly from
>> the above options, which is the best option or options to express these
>> graph transformations. Use case contributions to this document will help
>> determine the exact expressivity required.
>> NOTE: Let's not bias towards RIF when we have a number of different
>> options, most of which have been discussed considerably more in the WG
>> than RIF per se.
>>
>> - into a graph which is not isomorphic to the direct graph. -> into a
>> graph which is not isomorphic to the direct graph. This mapping of the
>> relational data conform with a particular schema that is non-isomorphic
>> to
>> structure in the relational database is called by database practioners a
>> "domain ontology" in contrast with the directly mapped "putative
>> ontology." Note that this is different use of the word "ontology" in the
>> database community is wider than that in the description logic (or OWL)
>> community, which uses it often to only refer to the schema.
>>
>> - The R2RML language MUST express transformations of the relational
>> graph
>> to produce the (virtual) RDF graph ->
>> The R2RML language MUST express transformations of the direct relational
>> database to produce the (possibly virtual) non-isomorphic RDF graph.
>>
>> - while but if  -> but if
>>
>> - DELETE These use cases are labeled custom-identifier.
>> - (perhaps the SQL draft suggests "YYHAB"^^xsd:string, I don't recall)
>> ->
>> DELETE and assume plain literal if we don't know by now.
>>
>> - DELETE Expressing the seqLength would be an opportunity for
>> micro-parsing as it encodes both the length (and integer) and the
>> metric.
>> NOTE: Or move to micro-parsing section
>>
>> 3.1.2.3
>> DELETE EDITORAL NOTE OR FIX
>>
>> - The R2RML language MUST enable transformation of SPARQL queries over
>> the
>> RDF view into efficient SQL queries over the relational database. -> The
>> R2RML language SHOULD allow the transformation of SPARQL queries over
>> the
>> RDF view into efficient SQL queries over the relational database without
>> materializing the view.
>>
>> NOTE: This sentence needs to be changed from a MUST to a MAY, as we
>> cannot
>> reall judge what an inefficient query is and we cannot force
>> implementations to NOT materialize a view, although I imagine many will.
>> After all, for some purposes an ETL approach may be best.
>>
>> 3.1.5
>> TThe mapping language SHOULD enable the use of user defined output
>> processing functions in order to transform values from the physical
>> database representation into some domain representation. -> The mapping
>> language SHOULD enable the use of user defined output processing
>> functions
>> in order to transform values from the relational database into some
>> customized domain representation more suitable for RDF.
>>
>> 3.1.5 Fix reference to XPath to proper reference style, or at least do
>> the
>> hyperlink over the entire "XQuery/XPath Functions and Operators" and not
>> just "XQuery/XPath Functions".
>>
>> NOTE: Shall we call in R2ML? Why not just say the RDB2RDF mapping
>> language? I imagine we can make up a sexier acronym, ala SQRL
>> (SQL-to-RDF
>> Language).
>>
>>  in version 1 -> as a core part of the RDB2RDF mapping language
>>
>> 3.1.6
>> NOTE: Not sure what this requirement means, honestly.
>>
>> 3.1.7
>> The mapping language SHOULD enable the creation of multiple Named Graphs
>> within one mapping definition. -> The mapping language SHOULD enable the
>> creation of named graphs (REFERENCE) within the mapping definition.
>> NOTE: Why multiple? Let's keep it simple and open-ended
>>
>>
>> 3.2.1
>> The mapping language SHOULD enable the declaration and use of namespace
>> prefixes -> The mapping language SHOULD enable the declaration and use
>> of
>> namespace prefixes in the RDF produced by the mapping.
>>
>> 3.2.2 METADATA - Static Metadata
>>
>> - The mapping language SHOULD enable the attachment of static metadata
>> (such as licensing information) to all RDF entities or instances of a
>> certain class. This is in particular important, when RDF is published as
>> Linked Data on the Web.->
>> The mapping language SHOULD enable the attachment of static metadata
>> (such
>> as licensing information) to some or all of the RDF produced by the
>> mapping language. This is particularly important when RDF is published
>> as
>> Linked Data on the Web. Furthermore, this metadata could be provenance
>> information as given by a provenance vocabulary [REF].
>>
>> - DELETE
>> The mapping language SHOULD support the preservation of provenance by
>> generating additional RDF triples according to a provenance vocabulary,
>> such as
>> http://sourceforge.net/apps/mediawiki/trdf/index.php?title=Guide_to_the_Proven
>> ance_Vocabulary
>> NOTE: As its a subset of the metadata requirement, and the Provenance XG
>> (who I just talked to today) is unlikely to have anything standardized
>> or
>> even quasi-standardized by the time our charter is up). See
>> "Furthermore,
>> this metadata could be provenance information as given by a provenance
>> vocabulary [REF]." sentence added above.
>>
>> - DELETE the entire Application Requirements section
>>
>> - ADD   The editors gratefully acknowledge contributions from: ->
>>     NOTE: add active working group members who have provided explicit
>> comments.
>>
>> - ADD explicit "References" Section and fix references to be in proper
>> W3C
>> style.
>>
>>
>>
>>
>>
>
>
>

Received on Thursday, 13 May 2010 13:18:07 UTC