Re: [spec-reviews] CSV on the Web (#55)

To discuss with the TAG:

> 1. We have a facility to enable transformations over tabular data using templates or scripts [1], to provide for transformations beyond those we’ve defined for JSON and RDF. In doing this we need to be able to indicate the format of both the result of the transformation and the format of the template or script that is being used.  

> We think that the “correct” way of doing this would be to use media types. However, it’s quite rare for templating syntaxes (such as Mustache) to have a registered media type, so instead we have opted to use URLs to name those formats and encourage users to use URLs in the form http://www.iana.org/assignments/media-types/{mediatype} when there is a registered media type. Is this the right approach to take or should we be more insistent on the use of a media type?

1. I think this is most appropriate, to future-proof the spec.  The last thing we want to do is to tie people to the list of formats the working group currently use (which may or may not be representative of everything out there) or to the list of everything currently in use (with no scope for future expansion).  Further, it makes sense to not restrict this to the list of media types, which has its own priorities and delays.

> 2. In the conversion to RDF, we want to use the ‘describes’ link relation defined in [2] to say that a particular row in the tabular data describes a particular thing (such as a person or event). Because this is RDF, the relationship has to have a URL.  

> However, as has been discussed elsewhere [3], IANA registered link relations do not have individual URLs and http://www.iana.org/assignments/link-relations/describes doesn’t resolve. Similarly, the link relation wiki doesn’t have individual URLs for link relations. We decided to create a URL for this relationship in our own namespace, with a reference to the proper definition (see discussion at [4]), but hope that this case might prompt the TAG to try to get some movement on this issue.

2.  I'm in favour, but I don't know enough about our relationship with IANA to know how to take this forward.  Suggestions?

> 3. The model of access that we’re assuming for CSV and other tabular data files is that someone will link directly to the CSV file (as currently) and that processors will need to retrieve a metadata file about that CSV based on the location of the CSV file. Note that metadata files are file-specific; we wouldn’t expect a single metadata file that includes information about every CSV file on a particular site.  

> We think that the “correct” way of getting this pointer to a metadata file (given that there is no scope for embedding information within the CSV file itself) is to use a Link header that points to the metadata file, and we have specified that here [5].  

> However, we recognise that there are many publishing environments in which it is impossible for users to set HTTP headers, particularly on an individual file basis. We have therefore specified two other mechanisms to retrieve metadata files, used only if the URL of the original CSV file doesn’t include a query string:

>  * appending ‘-metadata.json’ to the end of the URL to get file-specific metadata [6]
>  * resolving the URL ‘../metadata.json’ against the URL to get directory-level metadata [7]

> Neither of these feels great: they require users who can’t use Link headers to structure their URL space in particular ways, and they use string concatenation on URLs which is horrible. However, we can’t see any better alternative to meet our requirement for what is in effect a file-specific well known URI.


3.  I agree that appending a set string to a URL isn't ideal (and doesn't really fit with the kind of context-specific freedom we'd like people to have in setting their URL schemes).  So I understand the concern.  On the other hand, appending .json to a URL is common enough, and this is definitely human-readable, which helps — so I don't see a better way to solve the problem, so I think this is the lesser of the evils.  Might be worth an explicit review when CSVW and DWBP wind up, and the next charters are being set up?

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/55#issuecomment-107673370