Re: Comments on DCat

Dear Dan,

Thanks for clarification. This sounds more like a conformance
definition I and Phil suggested:

"Conformance means using terms from this vocabulary whenever they are relevant"

I think what is complicated here is that these vocabs aren't a simple
reference list plus the current definition of conformance in the DCAT
draft is very strong. (For example, as I read it not using the
dcat:DataDictionary property would make me non-conformant even if I
had no need of that property).

Rufus

On 26 July 2012 16:49, Gillman, Daniel - BLS <Gillman.Daniel@bls.gov> wrote:
> Rufus et al,
>
> Let me chime in on the meaning and usage of conformity.  ISO defines conformity as the fulfillment of requirements (ISO/IEC Guide 2: 1996, sub-clause 12.1).  Being that vocabularies are technical specifications, just as standards are, we can apply conformity to vocabularies just the same.
>
> What does it mean to conform to a vocabulary, i.e., what requirements are imposed by a spec that contains terms, meanings, relationships, and similar things?  The requirements come from the usage and implementation of such a spec not the spec itself.  Take the following simple vocabulary (gender classification):
> <1, male>
> <2, female>
> <3, other>
> where the meanings are as the words are used in English.  Conforming to this vocabulary would imply that if a male gender person needed to be classified, the first category would be applied.  This doesn't mean there can be no errors, it means there are no systematic ones.  For then, whatever system is used to classify gender, based on this vocabulary, is not conforming.
>
> Other kinds of requirements will come up, too.  For instance, if there are relationships between meanings, those need to be adhered to in a system that makes use of the vocabulary.  It is hard to enumerate all the possibilities, because vocabularies come in many kinds.  However, I hope this gives you the flavor.
>
> Yours,
> Dan
>
>
> Dan Gillman
> Bureau of Labor Statistics
> Office of Survey Methods Research
> 2 Massachusetts Ave, NE
> Washington, DC 20212 USA
> Tel     +1.202.691.7523
> FAX    +1.202.691.7426
> Email  Gillman.Daniel@BLS.Gov
> -----------------------------------------
> "Whatever it is, I'm against it!
> No matter what it is or who commenced it,
> I'm against it!"
> ~ Groucho Marx
> ------------------------------------------
>
>
>
> -----Original Message-----
> From: okfn.rufus.pollock@gmail.com [mailto:okfn.rufus.pollock@gmail.com] On Behalf Of Rufus Pollock
> Sent: Thursday, July 26, 2012 9:38 AM
> To: public-gld-comments@w3.org
> Cc: David Raznick; James Gardner; Maali, Fadi; Richard Cyganiak; Ross Jones
> Subject: 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/
>



-- 
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 15:53:46 UTC