PROF: `hasResource` limited to Profile, but usable for Standard as well

[jakubklimek]

The current definition of hasResource is:

###  http://www.w3.org/ns/dx/prof/hasResource
:hasResource rdf:type owl:ObjectProperty ;
          rdfs:range :ResourceDescriptor ;
          skos:definition "A resource which describes the nature of an artifact and the role it plays in relation to the Profile"@en ;
          rdfs:label "has resource"@en ;
          skos:usageNote "This property is analogous to dcat:distribution however the domain is not necessarily dcat:Dataset. dcat:Dataset and prof:Profile are not disjoint, so it is up to implementations to decide if these are equivalent properties"@en .

i.e. even though there is no machine readable rdfs:domain set to :Profile, the definition speaks about hasResource being in "relation to Profile". Now if I have a Standard (on the top of the profiling pyramid) and I want to use PROF to say that it too has resources (vocabulary, schemas, documents), I cannot do that using hasResource because by doing so I would say that the Standard is also a profile, which does not have to be true.

I would suggest rewording the definition to allow for hasResource to be usable also for Standards. Either

1. "A resource which describes the nature of an artifact and the role it plays in relation to the Profile or Standard" or
2. "A resource which describes the nature of an artifact and its role"

[rob-metalinkage]

My interpretation is that a Standard is automatically a "trivial" profile of itself with no explicit constraints - like rdfs:subclassOf is reflexive. I suppose this could be axiomitised - but is there any barrier to interpreting it this way?

[jakubklimek]

@rob-metalinkage Thanks. I think this is possible, but not intuitive from the spec.
Maybe this would have to be explained in the AP examples section, i.e. that

<http://www.w3.org/ns/dcat> a prof:Profile ;

so that it is clear, that you cannot distinguish a non-profile standard (e.g. a vocabulary) from a profile based on their types since both the vocabulary and the profile will be instances of both dcterms:Standard and prof:Profile when using hasResource like this.

[rob-metalinkage]

so that it is clear, that you cannot distinguish a non-profile standard (e.g. a vocabulary) from a profile based on their types since both the vocabulary and the profile will be instances of both dcterms:Standard and prof:Profile when using hasResource like this.

that is true - but there is no accepted vocabulary (or semantics) of standard types - so you would just need to define the additional standard types according to your needs.

If you think its worth defining a class hierarchy for different styles of profiling and models i guess it could be considered - it would need for example to be able to handle things like OWL vs RDFS vs SHACL defined models, OWL-punning for SKOS concept schemes for soft-typing more abstract classes, recommendations vs conformance tests and all the other nuances around the "type of standard" in the wild. I suspect this would be useful, but best done in a different scope.