Walk through cardinality of properties

Anonymous (not verified)

Published on: 30/04/2013 Discussion Archived

Now we have cardinality for properties in draft 2 v0.03 I would like to arise some potential issues:

- First a general question: should cardinality for non-mandatory properties always be in the 0..x form? I am not sure myself in this case as I assume it means cardinality applies once you decide to use that properties, but at the same time it is also a little bit confusing as I am used to that notation for "optional things". Even more confusing is that it looks like different criteria are applied to recommended and optional properties.

- Update/modification date -> should it be 0..1? (you don't have any such date until first update/modification)

- Identifier -> should it be 0..1, or even 1..1? (even when mulitple identifiers are possible to allow for local identifieres as Makx said, dct:identifier is defined as "An unambiguous reference to the resource within a given context", so this is about the unique identifier within a given system - in this case a given Catalog - even when other identifiers may apply for other systems, but you shouldn't be using dct:identifier for them)

- download URL -> should it be 0..n? what if we have several mirrors for the same Distribution for example?

- format -> should it be 0..n? what if we have a Dataset of zipped image resources in different formats for example?

- license -> should it be 0..1? (and thus optional) This is without doubt a must have, but unfortunatly my experience is that license information is frequently not easy to get or even impossible sometimes because even the data managers don't know about it.

Some other background references:

https://joinup.ec.europa.eu/asset/dcat_application_profile/issue/nolice…

https://joinup.ec.europa.eu/asset/dcat_application_profile/issue/cardin…

https://joinup.ec.europa.eu/asset/dcat_application_profile/issue/max-ca…

https://joinup.ec.europa.eu/asset/dcat_application_profile/issue/use-ma…

Component

Documentation

Comments

Anonymous (not verified) Mon, 15/07/2013 - 10:25

Two objections from my side:

(1) I would like to bring the cardinality of the license property at Catalog-level to discussion, as Makx' proposal was just referencing to section 7.4.x, namely the CatalogRecord-level.

Currently, the cardinality of the license property at Catalog-level is 1..1, but there are several catalogue providers (eg. Germany) that opted for supporting multiple licenses. Thus, a (common) license on the Catalog-level makes barely any sense.

As a result, I suggest to shift the license property from mandatory to recommended (section 7.1.1 -> 7.1.2).

(2) I think the use of cardinanlity in respect to multilanguage-support is somewhat misleading. A dataset should have one description, propably expressed in different languages. So IMHO cardinality should be 1..1. It is one information entity and an additional language should not provide more information but a different information « encoding » if you like.

This is true for many fields.

Makx DEKKERS Mon, 15/07/2013 - 13:04

Dominik, thanks for your comments.

My reponses:

(1) an earlier proposal (above in comments #18-#20) suggests to make licence information recommended for the Distribution. It may make sense to make the same move for the Catalogue. However, I'd like to point out that the licence information for the Catalogue is specifically about the licence under which the Catalogue itself can be used -- it does not specify the licences under which the Distributions of the Datasets in the Catalogue can be (re)used; those are specified in the licence information for each individual Distribution.

(2) the way that multilingual information is modelled requires the property to be repeated. Even if the text (e.g. of the description) conveys the same meaning in different languages, you can't put that information into one occurrence of the property, so you would need to say:

:DS1 a dcat:Dataset ; dct:description "English text"@en ; dct:description "Texte français"@fr .

Please note also that a parallel language version of text does not need to be an identical translation -- for example, the information may be adapted to the professional and cultural environment of the different audiences. The Application Profile does not put any requirements on what the text says, it just allows parallel language versions to be provided.

Makx DEKKERS Tue, 16/07/2013 - 18:16