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/