Re: Spec review request: CSV on the Web

Ivan and Jeni,

indeed, I had not caught that the media-type-declaration was only for
the annotations.

I am not sure I am able to judge whether the annotations make sense to
be exchanged between applications. I would feel it similar to the
copy-style and paste-style functions we can find, e.g., in Apple's
editors. I could imagine myself doing the same with datatypes of a cell
or column... Thus, if this makes sense, please consider it.

Yakov, would you consider this mail as a request to update the CSV
media-type declaration for this? It seems actually only missing on MacOSX.

paul


On 21/04/15 15:18, Ivan Herman wrote:
> Paul,
>
> I must admit I am not really familiar with the details of the clipboard format, so I am struggling to understand what is relevant to the work of this Working Group (for the tag list: the CSV on the Web Working Group).
>
> The work in the group indeed includes a (still-to-be-registered) media type definition:
>
>  http://www.w3.org/TR/2015/WD-tabular-metadata-20150416/#iana-considerations
>
> which is for a special json format that is used for the metadata created for a specific CSV content. I am not sure how any clipboard action would be relevant for this: the metadata file is, essentially, oblivious to any browser action.
>
> The example you refer to (HTML Tables possibly understood as spreadsheets or CSV files) seem to be more relevant to the specification of CSV per se. That definition is done at IETF:
>
>  https://tools.ietf.org/html/rfc4180
>
> the CSVW WG at W3C has been explicitly *not* chartered to define the CSV format itself exactly because this work is happening at IETF, although the group is happy (and encouraged) to contribute to the IETF process (and Yakov has been an active part of the Working Group).
>
> Can you tell me a bit more in details what you think this Working Group should do in terms of adding to, or modifying, the drafts?
>
> Thank you
>
> Ivan
>
>
>> On 19 Apr 2015, at 13:51 , Paul Libbrecht <paul@hoplahup.net> wrote:
>>
>> Dear Jeni and all,
>>
>> do I mistake or there is nothing about clipboard formats in this set of
>> specs?
>> Ideally, such would be in a media-type-declaration but it seems like the
>> one here would also be suited.
>> Basically: it would be clipboard flavour names for windows and UTI for OSX).
>>
>> The lack of such a convention  has made it that HTML tables are sniffed
>> and partially successfully copy and pasted from some browsers to some
>> spreadsheets (thus far: Firefox + Excel only)... This seems to be the
>> only way thus far and, indeed, xls or csv exports are pretty common as
>> an extra service of web applications whereas a selection, copy, and
>> paste would widely more intuitive.
>>
>> thanks in advance.
>>
>> Paul
>>
>>
>>
>> On 18/04/15 12:24, Jeni Tennison wrote:
>>> Hello TAG,
>>>
>>> The CSV on the Web Working Group would like to request that the TAG review the following Working Drafts:
>>>
>>>  Model for Tabular Data and Metadata on the Web -
>>>    http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/
>>>  Metadata Vocabulary for Tabular Data -
>>>    http://www.w3.org/TR/2015/WD-tabular-metadata-20150416/
>>>  Generating JSON from Tabular Data on the Web -
>>>    http://www.w3.org/TR/2015/WD-csv2json-20150416/
>>>  Generating RDF from Tabular Data on the Web -
>>>    http://www.w3.org/TR/2015/WD-csv2rdf-20150416/
>>>
>>> There are three things in particular that I’d like to draw the TAG’s attention to, where we have adopted a “pragmatic” rather than “correct” design:
>>>
>>> 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?
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> We’d obviously welcome wider review of the documents if you have time, but these are the three issues on which we’d particularly like your opinion.
>>>
>>> Thanks,
>>>
>>> Jeni
>>>
>>> [1] http://www.w3.org/TR/2015/WD-tabular-metadata-20150416/#transformation-definitions
>>> [2] http://tools.ietf.org/html/rfc6892
>>> [3] https://github.com/mnot/I-D/issues/39
>>> [4] https://github.com/w3c/csvw/issues/297
>>> [5] http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/#link-header
>>> [6] http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/#standard-file-metadata
>>> [7] http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/#standard-directory-metadata
>>> --
>>> Jeni Tennison
>>> http://www.jenitennison.com/
>>>
>>
>
> ----
> 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
>
>
>
>