Final grammatical comments on use-case document

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_Provenance_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 Wednesday, 12 May 2010 18:35:59 UTC