Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is dpv:Relation a Class or a Property? #112

Closed
pmcb55 opened this issue Sep 19, 2023 · 5 comments
Closed

Is dpv:Relation a Class or a Property? #112

pmcb55 opened this issue Sep 19, 2023 · 5 comments
Milestone

Comments

@pmcb55
Copy link

pmcb55 commented Sep 19, 2023

I notice that dpv:Relation is currently defined as:

dpv:Relation skos:prefLabel "Relation"@en;
    rdfs:isDefinedBy <https://w3id.org/dpv#>;
    rdfs:subPropertyOf skos:semanticRelation.

...but since it's a Property (specifically a rdfs:subPropertyOf of skos:semanticRelation), and not a Class, should it not be named dpv:hasRelation (as all properties should start with a lowercase character)...?

But then I notice that it's used as the rdf:type of 91 terms in DPV - meaning it's considered a Class, e.g.,:

dpv:hasDataProtectionOfficer skos:inScheme <https://w3id.org/dpv#>;
    skos:prefLabel "has data protection officer"@en;
    skos:broader dpv:hasRepresentative;
    skos:definition "Specifices an associated data protection officer"@en;
    a skos:Concept, dpv:Relation;
    dpv:isSubTypeOf dpv:hasRepresentative;

Hence my confusion. So is dpv:Relation really intended to be a Property or a Class?

(Note: The use of dpv:isSubTypeOf dpv:hasRepresentative above also appears strange (i.e., a Property being a sub-Class/Type of another Property?). Should DPV define a new property dpv:isSubPropertyOf, and use that in cases like this...?)
(Also note: tiny typo in the skos:definition value above too - i.e., 'Specifices' should be 'Specifies'.)

@coolharsh55
Copy link
Collaborator

Hi.

...but since it's a Property (specifically a rdfs:subPropertyOf of skos:semanticRelation), and not a Class, should it not be named dpv:hasRelation (as all properties should start with a lowercase character)...?

Hence my confusion. So is dpv:Relation really intended to be a Property or a Class?

dpv:Relation is the concept representing all DPV properties, similar to owl:ObjectProperty. It is not meant to be used directly, and only exists to collect DPV properties/relations together under one concept. So the name has a capital R.

(Note: The use of dpv:isSubTypeOf dpv:hasRepresentative above also appears strange (i.e., a Property being a sub-Class/Type of another Property?). Should DPV define a new property dpv:isSubPropertyOf, and use that in cases like this...?)

Regarding its modelling: skos:semanticRelation is an instance of owl:ObjectProperty, and has subproperties in SKOS e.g. skos:related. This is the why dpv:Relation also models the same relation so as to be used like a property for SKOS concepts. Using dpv:Relation like a class or skos:Concept is not what SKOS suggests, but AFAIK it isn't prohibited either because SKOS does not define Concept and semanticRelation to be disjoint. The definition of dpv:isSubTypeOf is not specific to a class or property, but only represents a vague hierarchical notion similar to SKOS broader/narrower.

Tbh, I don't like the messy implementation with 3 different semantics because implementation is a pain, but if it helps people fit DPV into their implementations then it is needed. The DPV modelling concepts (concept, relation) help produce the relevant RDFS/OWL class and property declarations in the other two semantic implementations. A solution to keep it clean might be to get rid of all "DPV" modelling concepts and just use SKOS. The additional value of separating DPV stuff from other SKOS-defined information doesn't seem to be worth the effort.

@coolharsh55
Copy link
Collaborator

On further thought, I think it would be best to drop this DPV defined concept modelling altogether, make RDFS+SKOS the default semantic implementation, and OWL as an alternative implementation.

@pmcb55
Copy link
Author

pmcb55 commented Sep 19, 2023 via email

@coolharsh55
Copy link
Collaborator

Thanks. I have sent an email for the change to the DPV's mailing list: https://lists.w3.org/Archives/Public/public-dpvcg/2023Sep/0024.html. Let's keep the issue open for discussion for now, and I will open a new issue for using RDFS+SKOS as default serialisation if the proposal is to be implemented.

@coolharsh55
Copy link
Collaborator

RDFS+SKOS is the default model now with OWL as an additional alternative serialisation. dpv:Relation is removed. This issue should therefore be closed if there are no further discussions on this topic. (to be reviewed on WED APR-24)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants