Comments (12)
A full definition for these properties is in PR #33
Could you please check if you are happy with it?
from geodcat-ap.
Tentative RDF definition:
<http://data.europa.eu/930/custodian>
a rdf:Property, owl:ObjectProperty ;
rdfs:label "Custodian"@en ;
rdfs:comment "Party that accepts accountability and responsibility for the data and ensures appropriate care and maintenance of the resource."@en ;
rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/custodian> .
<http://data.europa.eu/930/distributor>
a rdf:Property, owl:ObjectProperty ;
rdfs:label "Distributor"@en ;
rdfs:comment "Party who distributes the resource."@en ;
rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/distributor> ;
skos:exactMatch <http://www.w3.org/ns/duv#hasDistributor> .
<http://data.europa.eu/930/originator>
a rdf:Property, owl:ObjectProperty ;
rdfs:label "Originator"@en ;
rdfs:comment "Party who created the resource."@en ;
rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/originator> .
<http://data.europa.eu/930/principalInvestigator>
a rdf:Property, owl:ObjectProperty ;
rdfs:label "Principal investigator"@en ;
rdfs:comment "Key party responsible for gathering information and conducting research."@en ;
rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/principalInvestigator> .
<http://data.europa.eu/930/processor>
a rdf:Property, owl:ObjectProperty ;
rdfs:label "Processor"@en ;
rdfs:comment "Party who has processed the data in a manner such that the resource has been modified."@en ;
rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/processor> .
<http://data.europa.eu/930/resourceProvider>
a rdf:Property, owl:ObjectProperty ;
rdfs:label "Resource provider"@en ;
rdfs:comment "Party that supplies the resource."@en ;
rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/resourceProvider> .
<http://data.europa.eu/930/user>
a rdf:Property, owl:ObjectProperty ;
rdfs:label "User"@en ;
rdfs:comment "Party who uses the resource."@en ;
rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/user> ;
skos:relatedMatch dct:audience .
from geodcat-ap.
Thanks, @AntoRot .
RDF vocabulary and specification updated via PR #33
PROPOSED RESOLUTION: Implement changes in the current draft with the purpose of including these properties in version 2 of GeoDCAT-AP
from geodcat-ap.
No negative vote - resolution approved.
I'm going to merge PR #33 and close this issue.
I have created a new issue (#57) for the discussion about making the newly defined agent roles subproperties of the DCTERMS ones.
@AntoRot , @matthiaspalmer , @dr-shorthair , thanks for your contributions.
from geodcat-ap.
I agree with this very good proposal in line with what suggested in DCAT-AP section 7 related to the agent roles, i.e. "extensions to the base profile may be defined using additional properties with more specific meanings".
from geodcat-ap.
Thanks, @AntoRot .
@matthiaspalmer , may I ask if you have any comments on this proposal?
from geodcat-ap.
I think it is fine, but I think it would makes sense to also state:
- principalInvestigator, and processor as subproeprties of dcterms:contributor
- originator as subproperty of dcterms:creator.
- custodian, distributor and resourceProvider as subproperty of dcterms:publisher
At least, that is the semantics I read into these properties, do you agree?
I think it would be helpful with these statement to see when to use these properties as refinements of the more granular properties from dcterms.
from geodcat-ap.
Semantics and relationships between DC terms are traditionally rather informally defined. The canonical definitions of Dublin Core are not even RDF. So don't put too much weight on relationships to DC terms, and also don't interpolate to much back in DC.
from geodcat-ap.
I think we should indeed be cautious in defining sub-property relationships with DCTERMS, unless there's a use case bringing forward this feature as a requirement.
Besides @dr-shorthair 's points, the issue is also that the generic definitions used for roles in ISO 19115:2003 do not help have a better understanding of their semantics.
I would propose that we first add these properties in the GeoDCAT-AP namespace, and we then consider refining their definitions, if need be.
@matthiaspalmer , would this be an acceptable solution for you?
from geodcat-ap.
Of course @andrea-perego, my intention was to make implicit semantics explicit if it exists. Apparently it is not so.
Just to confirm, you are saying that there is a lack of explicit semantics in ISO 19115:2003 for these roles and that introducing the relations to DCTerms would introduce semantics that does not exist currently? That is, you are not saying that the suggested relations would go against some explicit semantics in ISO 19115:2003?
It would be interesting to know if the people involved here agree with my suggested subproperty statements and who would have the mandate to provide such an interpretation more formally.
I would also want to point out that every time this kind of non-decision is taken due to lack of semantics in clarifying what something really means, has the potential to create more confusion down the line. This confusion causes people who in many cases have less direct knowledge of how these standards came to be and what the intentions was to have long discussions and in the end make decisions. These decisions will be different in in different contexts and lead to interoperability problems. My personal experience with mapping various INSPIRE data to DCAT-AP is limited, but from what I have seen in only a few cases indicates that there is indeed a lot of confusion and the use of these roles are certainly one of these headaches.
from geodcat-ap.
In response to @dr-shorthair, I think you are referring to the original 15 elements. The DCMI Metadata Terms on the other hand are defined formally in RDF Schema with proper subproperty relations, e.g. dcterms:creator being a rdfs:subPropertyOf dcterms:contributor. I think these are the canonical definitions since some time. Here you can find the RDF Schema www.dublincore.org/schemas/rdfs/.
The properties and classes of DCTerms have rather broad definitions though, but this is by intention as it helps to maximize their use in a wide variety of situations. However, I would not agree that they are informally defined as they are defined in RDFS.
DCAT and many other metadata specification / profiles reuse and refine DCTerms properties (and classes) as much as possible. Hence, in my opinion, the DCTerms properties are very suitable and should be the basis introducing new properties if at all possible.
from geodcat-ap.
@matthiaspalmer said:
Of course @andrea-perego, my intention was to make implicit semantics explicit if it exists. Apparently it is not so.
Just to confirm, you are saying that there is a lack of explicit semantics in ISO 19115:2003 for these roles and that introducing the relations to DCTerms would introduce semantics that does not exist currently? That is, you are not saying that the suggested relations would go against some explicit semantics in ISO 19115:2003?
The problem is that the definitions of roles are quite vague in ISO 19115:2003 - they correspond to the ones in the mapping table in the GeoDCAT-AP spec:
https://semiceu.github.io/GeoDCAT-AP/drafts/2.0.0-draft-0.1/#table-responsible-party-roles
With such definitions, it is difficult to have a clear understanding of their semantic relationships with DCTERMS.
It would be interesting to know if the people involved here agree with my suggested subproperty statements and who would have the mandate to provide such an interpretation more formally.
If you think it would be useful, we can also create a specific issue on this.
My point was that the priority is to decide whether to define or not these properties. If we all agree to create them, we can further refine their definition in this version of GeoDCAT-AP, or in a later one.
I would also want to point out that every time this kind of non-decision is taken due to lack of semantics in clarifying what something really means, has the potential to create more confusion down the line. This confusion causes people who in many cases have less direct knowledge of how these standards came to be and what the intentions was to have long discussions and in the end make decisions. These decisions will be different in in different contexts and lead to interoperability problems. My personal experience with mapping various INSPIRE data to DCAT-AP is limited, but from what I have seen in only a few cases indicates that there is indeed a lot of confusion and the use of these roles are certainly one of these headaches.
It would important to collect all these issues and see whether and how we can address them. Besides those about the semantics of roles, do you have any other to report, @matthiaspalmer ?
from geodcat-ap.
Related Issues (20)
- Remove example for Media Type as it is confusing
- Improve notes on using embedded objects vs. references HOT 2
- Relation of various Agent classes used throughout the specification
- Revise usage of Licenses and Rights HOT 2
- DataService protocol mapped to `dct:conformsTo`
- Dataservice protocol list HOT 3
- Info: licenses in Flanders
- Access rights codelist issue
- Shared codelist for spatial concepts
- Format Publications Office HOT 1
- Info: on distribution / dataservice mapping rules HOT 1
- Info: entity conformity
- Info: mapping lineage statements
- pitfalls for metadata providers regarding expected mapping of distributions , digitaltransfers from ISO19115/19139 metadata to GeoDCAT-AP HOT 1
- Mapping of ISO metadata datestamp to DCAT HOT 4
- Mapping ISO dates to GeoDCAT-AP HOT 1
- The representation of the spatialResolution should be clearer specified and explained HOT 5
- The new GeoDCAT-AP should be defined as profile of the upcoming OGC GeoDCAT Specification HOT 2
- Mapping of metadataStandardName HOT 1
- applicableLegislationrequired for geospatial HVD´s HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from geodcat-ap.