Re: what about CSV fragments?

On 9 July 2014 10:15, Erik Wilde <dret@berkeley.edu> wrote:

> hello dan and ivan.
>
>
> On 2014-07-09, 11:05, Dan Brickley wrote:
>
>> On 9 July 2014 11:02, Ivan Herman <ivan@w3.org> wrote:
>>
>>> on the last remark: I have added you to the public-csw-comments@w3.org
>>> mailing list...
>>>
>>
> thanks!
>
>
>  As for the core remark: I think the simple answer is: it seems that no
>>> use cases were submitted (so far) that relied on fragment identifiers. If
>>> you have a real-life case for that: please send information to us and we
>>> would be happy to include it!
>>>
>> A few people have mentioned it, e.g. on the list
>> http://lists.w3.org/Archives/Public/public-csv-wg/2014Feb/0123.html
>> I think there's some awareness, but as Ivan says maybe it would help
>> to have a more explicit use case on the topic?
>>
>
> i don't have one from what i am doing right now, and i probably shouldn't
> just make one up. i was mostly surprised that nobody seems to be interested
> enough to even mention it in the UCR document. it seemed to me when it
> comes to scenarios such as annotations (reviewing/criticizing, or making
> any other kind of statement about CSV cells or rows/columns), communities
> such as linked data or government data probably would want to be able to
> identify CSV fragments. maybe not, and if nobody is interested in fragments
> enough to have them included, then they shouldn't be.
>
> to me, the question is: are you just looking at CSV resources as big
> chunks of data you're feeding into conversion or mapping workflows, or are
> you looking at CSV resources as being treated as persistent web resources.
> if the latter is a goal, then i'd be surprised if there were no scenarios
> where making statements about fragments wouldn't be useful.
>

There is the draft "URI Fragment Identifiers for the text/csv Media Type"
standard (<http://tools.ietf.org/html/draft-hausenblas-csv-fragment-02>,
mentioned in the list email linked above), and I think discussion so far
has mostly deferred to that document.

I think it's an interesting question, still, and I wonder whether data in a
CSV file should really be treated as a grid, for linking, (with cells
referred to using row + column coordinates) or as a collection of items
(with cells referred to using an item key - which might be a combination of
column values - and a property name). For example #cell=5,2 uses grid
coordinates, and is simple but susceptible to re-ordering. In contrast,
#foo.bar could point to a specific property of a specific item in the
table, but relies on a method of generating an ID for each cell in the
table.

Alf