Description
From: http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile/2015-February/000120.html We (in Norway) also added "Purpose" - which is a (legal) reference to the purpose of the making of the dataset (this heavily affects reuse within public sector).
Proposed solution
Add new property to Dataset to refer to a (legal) policy under which the dataset is published
Component
CodeCategory
improvement
Login or
create an account to comment.
Comments
I wonder whether the Core Public Service vocabulary could help address this issue.
The intended usecase here is to provide context that explains why (and under which restrictions) the data is created or collected. This is usually described in a law, which can be reffered to as a rdfs:Resource
E.g. the purpose of the Norwegian company register is described in a "law on legal entities": https://lovdata.no/dokument/NL/lov/1994-06-03-15?q=enhetsregister ( in Norwegian - Google translate is your friend)
Might be out of scope for DCAT-AP since this has more relevance for restricted sharing (public sector reusing public sector data)
This may already be possible using dct:conformsTo.
Thanks Makx. I considered reffering to a law as an established standard to be a stretch, but it might be better than inventing a property for a possible cornercase.
Another use case is provided by INSPIRE. All (meta)data and services available through the INSPIRE infrastructure obey to a legal act, namely, the INSPIRE Directive, requiring that data relevant to environmental policies are made available by EU Member States. Moreover, the INSPIRE Directive is accompanied by other legal acts (Regulations / Implementing Rules) describing how such resources shall be made available.
My earlier comment on the possibility of re-using the Core Public Service vocabulary (CPSV) was based on the fact that CPSV models this pattern.
I include below a description of CPSV taken from a Joinup page:
The Core Public Service Vocabulary was developed to help publish and exchange information about public services and, again, this has been piloted recently. There are a couple of features of the CPSV that are noteworthy and that, it is hoped, will be useful in other contexts. Firstly its Rule and FormalFramework classes. A Formal Framework will almost always be legislation (or a Directive) - something with legal force. These are typically implemented via policies that include service standards, input and output requirements etc. hence the Rule -> implements -> Formal Framework relationship. The cpsv:follows property that links a Public Service to the Rule(s) that define how it is run is deliberately left without a domain - that is, any 'thing' can follow a Rule.
Although in the text above the cpsv:follows property is given as subject a Public Service, in the CPSV RDF vocabulary the domain is left unspecified. So, it can be used for any resource - meta/data included. Moreover, classes cpsv:FormalFramework and cpsv:Rule can be useful at list to type the legal acts linked from data.
About the use of dct:conformsTo, I see an issue in relation to its (proposed) use for distributions, where the semantics is different. Note also that INSPIRE metadata require the inclusion of a conformity statement, which is meant to specify whether the representation of the described resource (data or service) is compliant with conceptual schema specified in the INSPIRE Regulation on the interoperability of data and services. In the current draft of the GeoDCAT-AP specification, this conformity statement is modelled by using dct:conformsTo.
I'm not against relaxing the semantics of dct:conformsTo, provided that we use it for just one purpose. But recommending the use of the same property for two different cases, and with different semantics, will cause semantic ambiguity, and wouldn't help DCAT-AP implementors and users.
Andrea, I may be diverting a bit from the discussion here, but it's interesting to say that the CPSV has evolved into what we call now the CPSV-AP, a common specification agreed between 10 Member States.
The notion of Formal Framework in the CPSV-AP is now aligned also with the ELI Ontology.
https://joinup.ec.europa.eu/asset/cpsv-ap/description
Sorry for my late response. This one escaped my attention. For the Dutch public dataportal we do consider the 'link to the law' a very useful property! It can be used for several purposes. Users can search for data which has to be collected by a certain law. Since the State Budget is a law you could even think of collecting financial datasets about spendings regarding a certain chapter of the budget.
Besides that, the law is also quite a fancy indicator for subject/theme. A nice bycatch.
Remains the choice for a good property from a well recognised vocabulary... I agree very strongly with Andrea that we need a property that can not be confused with the semantics of dct:conformsTo.
But imho the CPSV unfortunately doesn't offer a flawless solution. We would like to link a dcat:Dataset directly to legislation. I would say that in the CPSV model a Dataset is Output from a Service. That would make the path from Dataset via Service and Rule to FormalFramework quite a long one. This is way too much to add to the DCAT-AP. And I don't know of Services descibed in CPSV yet to which we could link Datasets. Also the range of cpsv:follows is cpsv:Rule, which has the context of the Service, and not cpsv:FormalFramework, which corresponds to the law.
Unfortunately I don't have the perfect solution either. We beleive that links to the law are very useful and powerful, especially for government information. Since we didn't find a vocabulary that defined a term with exactly the semantics we are looking for, we are using our own term "grondslag" for the time being. We made it a sub-property of dct:source which also stretches the semantics to a limit, I will admit immediately.
The working group decided in the meeting of 10 June 2015 that this functionality will not be added to the application profile.