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

Thanks. Should the need arise, I will quote this email chain verbatim in a
GitHub ISSUE. Jeremy

On 26 February 2015 at 13:13, Ivan Herman <ivan@w3.org> wrote:

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