Re: New section on translation schemes in R2RML spec

Richard- I appreciate your efforts in putting this together. I reviewed the
translation scheme section you added to the spec [1] and my comments are
below.

* "achieded" -> "achieved"
* "When a logical table column is mapped to RDF using a translation scheme,
then the scheme is searched for concepts whose skos:notation matches the
data value.", for clarity change the final "data value" to "column value".
* "... specified using the rr:translationScheme property, whose values MUST
be translation schemes. A translation scheme is a set of one or more
string-IRI pairs." - I stumbled over this when I read it because it goes
from talking about a translationScheme property to a conceptual description
of a translation scheme as a "set of pairs". My immediate question is how I
make a property point to a set of pairs. Maybe it is implied, but I think it
should more clearly state that the translationScheme property refers to a
"translation scheme" resource. Or maybe to a "ConceptScheme"?
* Add something like this to the spec: If multiple matching concepts are
found then it is a mapping error.
* I don't see why "broadMatch" is required when performing a 1:N
translation. On my reading of SKOS, "exactMatch" is transitive and so we can
just use "exactMatch" for each of the concepts. The way that the R2RML spec
defines the semantics of exactMatch, closeMatch, and broadMatch they are all
identical.
* Do we need to address the issue of inconsistent SKOS data models defined
in the mapping document?
* What potential issues arise from supporting 1:N translations?
* I don't know enough about SKOS to know whether we are abusing it or using
it correctly for this purpose.
* For the 1:N translation case I think it would be nicer to write the
following. Is this considered bad form for SKOS?
<http://chef.example.com/cuisines/indian> a skos:Concept;
     skos:inScheme <http://chef.example.com/cuisines>;
     skos:notation 1;
     skos:notation 2.
* Final questions for the group as a whole, not necessarily directed at you:
What alternative approaches to defining translation schemes were considered?
What are the tradeoffs of the various options? Are there examples of SKOS
being used in this way, if so what can we learn from them?

My sense is that our remaining time before last call should be focused on
finalizing the features that are currently in the specs rather than trying
to add a new section such as this.

-David

[1] http://www.w3.org/2001/sw/rdb2rdf/r2rml/#translation-schemes