Modeling: define or remove dprod:Protocol (properties vs URI/SKOS)

[jgeluk]

Tracks part of #98. Either enrich dprod:Protocol with useful properties (e.g., spec URI, version) or remove and let dprod:protocol point to a URI/SKOS concept. Refs #98

[jgeluk]

We need a decision on this. @tonyseale

[jgeluk]

Clarification: define or remove dprod:Protocol (properties vs URI/SKOS)

Issue: [#143] considers whether dprod:Protocol should be elaborated as a first-class class with properties, or removed in favor of using external URIs/SKOS concepts referenced by dprod:protocol.

Current ontology fragments:

dprod:Protocol
  a owl:Class, rdfs:Class ;
  dct:description "A detailed specification, possibly including a specific version, for how to communicate with a service."@en ;
  rdfs:isDefinedBy dprod: ;
  rdfs:label "protocol" ;
.

dprod:protocol
  a rdf:Property, owl:ObjectProperty ;
  dct:description "A protocol (possibly one of many options) used to communicate with this data service."@en ;
  rdfs:isDefinedBy dprod: ;
  rdfs:domain dcat:DataService ;
  # rdfs:range left open to allow flexibility
  rdfs:label "protocol" ;
.

Option A: Keep and define dprod:Protocol

• Enrich the class to support identification and linking to authoritative specs. Example shape:

dprod-shapes:ProtocolShape
  a sh:NodeShape ;
  sh:targetClass dprod:Protocol ;
  sh:property [ sh:path dct:identifier; sh:datatype xsd:string ] ;
  sh:property [ sh:path dct:title;     sh:datatype xsd:string ] ;
  sh:property [ sh:path dct:description; sh:datatype xsd:string ] ;
  # choose one for versioning
  # sh:property [ sh:path sdo:version;  sh:datatype xsd:string ] ;
  # sh:property [ sh:path owl:versionInfo; sh:datatype xsd:string ] ;
  sh:property [ sh:path rdfs:seeAlso;  sh:nodeKind sh:IRI ] ;
  # optional alignment to external vocabularies
  # sh:property [ sh:path skos:exactMatch; sh:nodeKind sh:IRI ] ;
.

# DataService side stays typed to the class
dprod-shapes:DataService-protocol
  a sh:PropertyShape ;
  sh:path dprod:protocol ;
  sh:class dprod:Protocol ;
.

Pros: strong typing, allow rich metadata; Cons: requires maintaining Protocol instances or a profile.

Option B: Remove dprod:Protocol and point to external URIs/SKOS

• Delete the class; let dprod:protocol point to an IRI (e.g., IANA schemes) or a SKOS Concept. Example shape change:

# Option B1: minimal, accept any IRI
dprod-shapes:DataService-protocol
  a sh:PropertyShape ;
  sh:path dprod:protocol ;
  sh:nodeKind sh:IRI ;
.

# Option B2: encourage SKOS Concept usage
dprod-shapes:DataService-protocol
  a sh:PropertyShape ;
  sh:path dprod:protocol ;
  sh:class skos:Concept ;
.

Pros: flexible, reuse external registries; Cons: less structured metadata unless a concept scheme is mandated.

Acceptance criteria

• Decide A or B and document rationale in the spec/README.
• If A: add properties to dprod:Protocol, create/adjust SHACL ProtocolShape, keep DataService-protocol with sh:class dprod:Protocol; add examples.
• If B: remove dprod:Protocol class, adjust DataService-protocol to sh:nodeKind sh:IRI or sh:class skos:Concept; add examples.
• Rebuild and verify published site reflects the decision.

Refs #98

[srirambles]

Raised as OMG issue https://issues.omg.org/browse/DPROD-33