Re: Comments on DCat

Notes from chat with Phil today:

* Clarify "conformance". Suggest either removal (is it relevant for
vocabs?) or phrasing as: "Conformance means using terms from this
vocabulary whenever they are relevant"

* Re OKFN comments on properties for Dataset does not matter too much
once conformance is clarified (e.g. dataDictionary etc). "Individual
implementors" are likely to put specific constraints on presence of
properties

* dc:partOf: just use it! (PA: you can always add RP: however fact
that DCAT does currently list a bunch of dc items as if they are
recommended / suggested / required creates some confusion)

* Re Distribution / Resource: thought was that it would make sense to
have a new Resource superclass (taking location of Distribution in the
current diagram and for Distribution to be a subclass (along-side
other classes).
   * Sub-point: properties of Distribution would usually be properties
of sub-classes of Resource and may not apply in all cases (e.g. size
not relevant for WebService ...?)

* Other Distribution/Resource property points: general agreement
(probably not *that* big a deal either way but OKFN suggestions seem
useful and some may be worth adopting)
  * cf discussion on conformance. If this is dealt with could possibly
ignore all of these comments since people can add as needed.

Rufus

On 31 May 2012 16:59, Rufus Pollock <rufus.pollock@okfn.org> wrote:
> Hi All,
>
> A few weeks ago I spoke in some detail with Faadi Mali about DCat and
> to discuss some suggested modifications. The results of this
> discussion are inlined below. I'd be interested to hear people's
> thoughts and whether people would be happy to make these
> modifications.
>
> Regards,
>
> Rufus
>
> ## Dataset concept
>
> * Remove dcat:accessURL and just use Resource (Distribution)
>
>   * Status: agreed and in progress
>
> * Remove dcat:dataDictionary (leave for v2 or v1.1)
>
>   * Better to introduce once practice has established a need and consistent
>     usage. One should be parsimonious in generating new properties at this
>     early stage.
>   * Also currently has Inconsistent usage
>   * Status: ticket and discuss
>
> * Remove dcat:dataQuality (ditto)
>
>   * As previous
>
> * Remove dcat:granularity (or specify better)
>
>   * As previous
>
> * Remove dc:references (is it used and how would it be used)
>
>   * Suggest removal since for linking datasets we should have (at some point):
>     derives, links_to, sibling, partof
>   * Remember that people can always add other attributes they want ...
>   * Status: ticket and discuss
>
> * Make clear what is optional versus required (?) e.g.
>
>   * Designate as optional: dcterms:accrualPeriodicity
>   * Designate as optional: dcat:theme
>   * Resolution: ticket and discuss
>
> Possibly to add (but will not happen for the present):
>
> * version
> * partof
>
> ## Distribution / Resources concept
>
> * Rename dcat:Distribution to dcat:Resource
>
>   * Distribution has a strong connotation from software of a packaged version
>     of the entire dataset whereas, in fact, in most cases it will be a data
>     file or API associated to the Dataset for which the term Resource is more
>     appropriate.
>   * Status: ticket and discuss
>
> * Extend the set of attributes a Resource may have
>
>   * [Optional] Add dc:title to Resource
>   * [Optional] dcat:mimetype - see
> http://docs.ckan.org/en/latest/domain-model-resource.html
>
>     * http://docs.ckan.org/en/latest/domain-model-resource.html#resource-format-strings
>     * could also have mimetypeInner
>
>   * [Optional]: hash (md5 or sha1, must be of form md5:{hash} or sha1:{hash})
>   * [Optional]: dc:created and dc:modified
>
> * Size: define it as bytes and add sizeString. That is:
>
>   * dcat:size = number / size in bytes
>   * [Add] dcat:sizeString: informal string description size e.g. >1Mb



-- 
Co-Founder, Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/

Received on Thursday, 26 July 2012 13:38:08 UTC