Re: what about CSV fragments?

hello alf.

On 2014-07-09, 11:49, Alf Eaton wrote:
> 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.

this draft has become http://tools.ietf.org/html/rfc7111, so there is an 
existing specification for how to identify CSV fragments. as the 
co-author of this spec, i was mostly wondering why nobody seems to be 
all that interested. michael (the original and first author) used to be 
part of the linked data community, and his main interest was to make 
sure that CSV can be linked to, including fragments.

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

through the RFC's history 
https://datatracker.ietf.org/doc/rfc7111/history/, there was a bit of 
back and forth, balancing issues of simplicity and stability. i don't 
think there's one true answer here. the current RFC definitely 
emphasizes simplicity over stability. in the end, the goal was to avoid 
layering an additional model on top of CSV (such as the IDs you 
mention), and then you end up with simple identifiers that will easily 
break when the CSV changes.

having looked at various media type fragment identifier methods over the 
years, there's actually an interesting set of "best practices and design 
patterns" one could extract, that depend on (a) the richness/design of 
the media type itself, and (b) the expressiveness/stability required 
from the fragment identifiers. but this is a different issue and 
probably just a weird hobby of mine.

thanks and cheers,

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Wednesday, 9 July 2014 10:01:07 UTC