Re: no need to create new GitHub ISSUE for access to literal value from URI template

> On 26 Feb 2015, at 04:59 , Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
> 
> Hi - at yesterday’s weekly teleconf [1] we talked about needing to access the literal value from a cell from a URI template.
> 
> The example cited relates to the use of multiple missing values: e.g. tokens `unknown` and `withheld` are both “null” values, but mean different things. Given occurrence of either of these tokens in a dataset, the cell value would be assumed to be null (empty). I had argued that one might want to use a URI template (in a virtual column) to include information in, say, an RDF conversion about _why_ the data value was missing. Given that URI templates operate on the _canonical value_ of the cell (not the literal value), the cell value in these situations would already be set to an empty string “” and thus unable to use the `unknown` or `withheld` assertion.
> 
> I agreed to open a new ISSUE in GitHub for this.
> 
> However, having thought about this further, my scenario is flawed: without if/then/else logic my URI template would be triggered for _every row_ - including those rows with non-null values too. Yuk.

Actually, it is not that bad. I remember we have touched upon this, and the approach proposed was to introduce some sort of an extra variable, like we already have a number of '_XXX' type variables. It is a bit of a hack, but if we introduce a variable scheme of the sort "_raw_NAME", where 'NAME' should be replaced by the name value of a column, then the expansion process could work easily without any further ado. After all, the way it works (at least when I played with it) is to collect, for each row, a separate object (in Javascript parlance) for the different usable template variables (the ones we defined, plus an entry for each 'name') and then let the expansion process (library, external function, whatever) work. No if-then-else, thus.

> 
> @JeniT noted that the “unions of datatypes” approach (see ISSUE #223 [2]) might be a better fit for this problem - which is possible. Alternatively, it seems that if this is important for data publishers, it would be appropriate for them to include an additional "nil-reason” column in their data to document this kind of information rather than trying to overload a single column!
> 

That is another issue of course: is it really necessary to introduce a new feature? As usual (I have become the 'grudgingly approve' person in the group), my first instinct would be indeed to use the 'nil-reason' column. Ie, let the data producer do a slightly better job and not add yet another feature creep to our system. I do not know whether this is realistic, though.


> I can’t think of another reason as to why I would want to access the literal cell value from a URI template - so I don’t think it’s pertinent to open the new ISSUE … and I haven’t! Please advise if you feel otherwise.

Administratively, the discussions we just have are typically part of an issue:-) I raised the issue of the multiple datatypes per cell, because one of the use cases that was submitted to the group seemed to require it (although, it turns out, he does not need it any more, ironically!), although I continue to be _very_ "grudgy" about it! But have the discussion on github is probably a good practice.

(At this point, it is probably a good idea, if you decide to add it as an issue, to quote these mail verbatim:-)

Cheers

Ivan


> 
> Jeremy
> 
> [1]: http://www.w3.org/2015/02/25-csvw-minutes.html
> [2]: https://github.com/w3c/csvw/issues/223


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704