- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Tue, 14 Feb 2012 16:57:11 +0000
- To: Sarven Capadisli <sarven.capadisli@deri.org>
- Cc: Government Linked Data Working Group WG <public-gld-wg@w3.org>, Government Linked Data Working Group Issue Tracker <sysbot+tracker@w3.org>
On 10 Feb 2012, at 14:07, Sarven Capadisli wrote: > In any case, I think it is important to distinguish the following cases for the record: > > a) Data accessible only by interacting with the web application e.g., it may require a login, sessions, or XHR. > b) Direct accessible links i.e., data can be retrieved independently with an HTTP request. > > For (a), I think we are slightly out of luck. Since the dcat:Distribution class caters to any distribution type (including the HTML page for the downloads), the following would satisfy the very last stop to access the data: > > ex:dataset1 > a dcat:Dataset ; > dcat:distribution <http://example.gov/downloads/> . A common use case is that someone is looking for data on a certain topic in CSV or Excel format, and they don't mind if they have to click through a download page or form to get to the data. Many catalogs are organised to support this use case. data.gov.uk example: http://data.gov.uk/dataset/spotlightonspend-transactions-download The catalog knows that this is in CSV format, but you actually have to do several clicks before you get to the actual data (which is a zipfile with a CSV inside). So the URL in the catalog (http://www.spotlightonspend.org.uk/datadownload.aspx) is *not* in CSV format, but the dataset *is* distributed in CSV format. I think it's important that DCAT can represent this situation, including the fact that CSV is available. The current design meets that requirement; with your proposal it no longer works. Best, Richard
Received on Tuesday, 14 February 2012 16:57:44 UTC