search

w3c / dpv

Data Privacy Vocabularies and Controls CG (DPVCG)
https://w3id.org/dpv
Other
32 stars 21 forks source link

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

Closed pmcb55 closed 1 month ago

pmcb55 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

Hiya Harsh,

I think it would be best to drop this DPV defined concept modelling altogether

Yeah, I totally agree.

make RDFS+SKOS the default semantic implementation

Yep, I totally agree with this too!

Cheers,

Pat.

On Tue, Sep 19, 2023 at 10:38 AM Harshvardhan Pandit < @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/w3c/dpv/issues/112#issuecomment-1725068451, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHKXJLIIFMSF6NOUXO5I4LX3FKZBANCNFSM6AAAAAA45YMOQY . You are receiving this because you authored the thread.Message ID: @.***>

coolharsh55 commented 8 months ago

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 commented 1 month ago

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)