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.

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

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

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 07:38:35 UTC