- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 9 Dec 2015 09:52:50 +0100
- To: "Lars G. Svensson" <L.Svensson@dnb.de>
- Cc: W3C CSV on the Web Working Group <public-csv-wg@w3.org>, Gregg Kellogg <gregg@greggkellogg.net>, Jeni Tennison <jeni@jenitennison.com>
- Message-Id: <0D2D9E41-7164-474D-A03D-96EEEEB03050@w3.org>
(Cc-ing to Gregg & Jeni, as an additional ping to get their attention…) Hey Lars, > On 4 Dec 2015, at 12:26, Svensson, Lars <L.Svensson@dnb.de> wrote: > > Dear all, > > While reviewing the WG documents (excellent work, large kudoi to the WG!) Thank you! > and thinking of how we could produce compatible data at our place, I stumbled over the url annotation on tables as defined in the metadata vocabulary, §5.4 [1]. The specification says that in the table metadata the url (URI?) is mandatory and should point to the table the table description describes, referring to the definition of url in the tabular data model [2] that says that the value of the url might be null. > > At first sight my reading would be that for each table I describe with a table annotation in the metadata document, I MUST have a url property pointing from the metadata document to the described table. If so, that would be a major implementation obstacle at our place. Our main use case for producing tabular data is that customers can go to the catalogue, select a number of object descriptions and export those as CSV. When the customer downloads the data, we would provide a Link-Header pointing to the metadata document describing the CSV format. It would, however, be almost impossible to point back from that metadata document to _all_ instances of CSV files ever created (particularly since that would also have privacy concerns, since it would be possible to see what other customers have downloaded). > > This boils down to the following question(s): > > 1) Is my understanding of the use of the url property in the table metadata correct? > 2) If so, can I solve it by simply setting it to null? That is my reading and, I think, that was our intention. If set to null, that means that the implementation makes the 'pairing' between the metadata and the data itself which, as far as I can see, is exactly what you do. > > And one further question regarding dialect: > > The dialect is an optional property in the table description. From my understanding, however, the dialect has major impact on the processing of the table. In the tabular format definition, core annotations are those that have impact on processor behaviour [3]. Does that mean, that dialect should be a core annotation or is that solved by defining default values for the dialect? First of all, the dialect is optional. Furthermore, the dialect only provides hints; the parsing algorithm in the model document[1] is non normative. In other words, if your processor produces an annotated data model, that is fine; how the processor gets there, so to say, is not something these recommendations control… I hope this answers your questions! Cheers Ivan [1] http://www.w3.org/TR/2015/PR-tabular-data-model-20151117/#parsing > > [1] http://www.w3.org/TR/2015/PR-tabular-metadata-20151117/#tables > [2] http://www.w3.org/TR/2015/PR-tabular-data-model-20151117/#dfn-url > [3] http://www.w3.org/TR/2015/PR-tabular-data-model-20151117/#dfn-core-annotations > > Thanks for any insight, > > Lars > > *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** > -- > Dr. Lars G. Svensson > Deutsche Nationalbibliothek > Informationsinfrastruktur > Adickesallee 1 > D-60322 Frankfurt am Main > Telefon: +49-69-1525-1752 > Telefax: +49-69-1525-1799 > mailto:l.svensson@dnb.de > http://www.dnb.de > > ---- Ivan Herman, W3C Digital Publishing Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Wednesday, 9 December 2015 08:53:05 UTC