ACTION-73 Summarise discussion and make a proposal for agreement or not

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 

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.



Phil Archer
W3C eGovernment
+44 (0)7887 767755

Received on Friday, 3 August 2012 17:08:48 UTC