Re: Direct Mapping spec. comments (mostly editorial)

* Barclay, Daniel [USA] <Barclay_Daniel@bah.com> [2012-09-13 17:27+0000]
> Regarding the A Direct Mapping of Relational Data to RDF specification
> currently at http://www.w3.org/TR/rdb-direct-mapping/:

Thank you very much for the excellent review. Except where noted below, your proposals have been incorporiated into r1.39 of the editors draft <http://www.w3.org/2001/sw/rdb2rdf/directMapping/LC/>, to be published later this month.


> In 2.1: "Each foreign keys produces ...":  
> 
>   That should be "Each ... key ..." (or "Each of the ... keys ...").

done


> In 2.1: "... the row identifiers (<Addresses/ID=18>) for the referenced
>   triple.":
> 
>   That should be "... the row identifier ..."

done


> In 2.2: "Foreign keys referencing candidate keys":
> 
>   Was the "candidate" supposed to be "composite"?

"candidate" -- in SQL, foreign keys have to reference a list of columns which form a candidate key, i.e. have unique values over the rows.


> In 2.2: "More complex schemas include composite primary keys.":
> 
>   That "composite primary keys" should be "composite keys" (that section
>   isn't talking about _primary_ keys).

that's consistent with the example -- done.


> In 2.2: "Per the People tables's compound foreign key...": "table's"

done


> In 2.3: "The triples involving <Department/ID=23> would be substituted 
>   with the following...":
> 
>   That should be "... replaced with ..."

done


> In 2.4: "If there is no primary key, rows implies a set of triples with
>   a shared subject, but that subject is a blank node.":
> 
>   That's broken (and it's not clear what the intent was).

s{rows}{each row}


> In 2.5: "... foreign keys reference candidate keys and candidate keys 
>   are ...":
>   That might be clearer as: "... foreign keys refer to candidate keys 
>   ..."

not done
before changing, we'd have to check if "reference" aligns with classical relational rhetoric.
i think it's good enough now.


> In 2.5: "... keys with mutual column names.":
> 
>   That "mutual column names" seems ambiguous.  
> 
> In 2.5: "For clarity; ...":  semicolon -> comma
> 
> 
> In 2.5: "For clarity[,] here is ... to clarify ...": redundant
> 
> 
> In 2.5: "For clarity[,] here is ... to clarify ...": 
> 
>   Given the multiple foreign keys, it would be clearer if the text had 
>   some pointer to a key (representive) one.

s{This example includes several foreign keys with mutual column names. For clarity, here is the DDL to clarify these keys:}
 {Here is DDL for a schema with references to a <code>Projects</code> table which has no primary key:}
i think this is an improvement and addresses or obviates the above four comments.


> In 3: "A base IRI defines a web space for the IRIs in this graph.":
> 
>   That "web space" should probably be "URI space" (well, "IRI space").

i can't tell you what a "web space" is, or even that i know one when i see one, but i'm reluctant to address philosophical changes at this late stage.


> In 3: "An SQL table has a set of uniquely-named columns and a set of 
>   foreign keys, each mapping a <column name list> to a <unique column 
>   list> (a list of columns in some table).":
> 
>   That wording seems ambiguous (between grouping as "has (A and B), 
>   each ..." vs. as "has A and (B, each) ... ").
> 
>   Maybe "... and a set of foreign ... " should be "... and has a set of 
>   foreign ... "

done


> In 3: Re single quotes around characters:
> 
>   If that's because they're characters instead of strings, remember that 
>   this is English, not computer language that uses single quotes for 
>   characters.
> 
>   If the specification is supposed to be in American English, then those 
>   should be double quotes.  

not done

the current notation is consistent with other specs, e.g. XML fifth edition
  http://www.w3.org/TR/REC-xml/#NT-EmptyElemTag
. i'll keep this distinction in mind for the next spec.


> In 3: "blank node that is unique to this row.":
>    
>   That doesn't (locally) specify the scope of that uniqueness.  Is that
>   scope specified somewhere?

RDF blank nodes are globally unique. given any two RDF documents, the bnodes are defined to be disjoint. given that, i think this text suffices.


> In A.1: "The definitions follow a type-as-specification approach, thus 
>   the models are ...":  
> 
>   The comma should be a  semicolon (or a sentence break).

done


> In A.4.[35]: "Replace the string with the IRI-safe form of that 
>   character":
> 
>   That doesn't make sense grammatically (the reference to "that 
>   character" has no antecedent), and maybe not otherwise either.
> 
>   Should that be something like "replace each problematic character 
>   in the string with ... character" (with "problematic" replaced with 
>   a more technical term)?

s{form of that character per section}
 {form per section} 2x
note change to normative definition above


> In A.4.[36]: (with English Syntax enabled) "lexical form of ...": 
> 
>   It seems that that should be "Lexical form of ..." (capitalized like
>   sibling noun phrases).
>  
>   (indicative- or imperative-mood(?)) sentence

the "English" notations in appendix A quote the above normative definitions where possible. the change of mood is a bit awkward, but provides good accountability.


> In A.4.[37]: " ... join(...) ...":
> 
>   Is "join(...)" defined?

nope. it's used here like it's "concat". i understand it's relatively accepted in set notations but have no evidence of that myself.


> In B: "... inspired by previous approach ...":
> 
>   That probably should be "a previous approach" (or "previous 
>   approaches").

s{inspired by previous approach ...}
 {inspired by the previous approaches in ...}


> Daniel
> 
> 

-- 
-ericP

Received on Tuesday, 18 September 2012 13:15:33 UTC