- From: Phil Archer <phila@w3.org>
- Date: Fri, 03 Aug 2012 18:08:18 +0100
- To: Public GLD WG <public-gld-wg@w3.org>
I took an action item at the end of last week's call to summarise the discussion we had around DCAT with Rufus Pollock and try and boil it down to specific resolutions/issues. Context: OKFN is finalising its spec for use in CKAN. It includes vocabulary terms, for which the hope is to basically say "use DCAT" but also a set of minimum terms that must be used and descriptions of APIs etc. See [1]. Issue A ======= Conformance to a vocabulary. The suggestion at the beginning and the end of the call was conformance to a vocabulary basically means using the available terms and not inventing new ones for something covered by it. Individual implementations are free to state that particular terms are required and others are optional (and perhaps that some will always be ignored) but that such rule books are application specific. An attempt to codify this is included in the ADMS editor's draft [2] Proposed Resolution: that the following wording is broadly correct (although it is, of course, subject to improvement) "Conformance to this vocabulary means using its classes, properties and relationships. It does not necessarily mean using every term and there are no terms that are mandatory. However, the inclusion of a term signals that the Working Group has found it to be useful. Applications MAY specify a minimum set of terms that publishers must use if their data is to be processed, and MAY also specify controlled vocabularies as acceptable values for properties. This specification treats such restrictions as application-specific and therefore makes no such restrictions. However, the Working Group recognizes that restrictions (cardinality constraints) are often important. A non-conformant implementation is one that uses a term other than one defined in this document that could reasonably be used." Issue B ======= CKAN includes pointers to APIs associated with a dataset as well as static files. It is misleading to talk about a Distribution when describing an API as the term is associated much more with static files, things with defined size, last update dates and so on. There appear to be two options: Option A ======== A single class called dcat:AssociatedResource that has a property along the lines of dcterms:type that tells you if it's a download, an API, or something else. Option B ======== Distinct classes for downloads and APIs. The idea of a superclass of these two was discussed but the general mood seemed to be that no such superclass was necessary. So we'd probably have dcat:ditribution -> dcat:Distribution as now dcat:associatedResource -> dcat:DatasetResource (or something similar) Richard seemed to arguing more for A but the mood seemed to be more in favour of B. Issue C ======= Is accessURL necessary for downloadable files or is it always the case that the downloadable file *is* the accessURL. This was originally raised by Ed Summers [3] (I think Lincoln was warming up to give the Gettysburg address at the time and it has been handed down to us now as ISSUE-7). I don't think we resolved this issue definitely on the call but I believe the reluctant view is that in some instances it has its uses and therefore it should be retained. [1] http://spec.datacatalogs.org/ [2] http://dvcs.w3.org/hg/gld/raw-file/default/adms/index.html#conformance [3] http://www.w3.org/egov/IG/track/issues/38 -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Friday, 3 August 2012 17:08:48 UTC