Difference in prefLabel & definition of service type depending on the encoding/profile

[heidivanparys]

I noticed that the preferred label and the definition of a service type are different depending on the encoding (or profile, see explanation below).

E.g. WMS:

http://www.opengis.net/def/serviceType/ogc/wms :

When looking at the different profiles and encodings via http://www.opengis.net/def/serviceType/ogc/wms?_profile=alt:

application/ld+json

http://www.opengis.net/def/serviceType/ogc/wms?_profile=concept&_mediatype=application/ld%2Bjson:
redirects to http://defs-dev.opengis.net/vocprez/object?uri=http://www.opengis.net/def/serviceType/ogc/wms&_profile=dd&_mediatype=application/ld+json:

application/rdf+xml

http://www.opengis.net/def/serviceType/ogc/wms?_profile=concept&_mediatype=application/rdf%2Bxml:
redirects to http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/serviceType/ogc/wms&_mediatype=application/rdf+xml:

The difference seems to be that for application/ld+json, parameter _profile=dd is added on the redirect.

What are the correct values?

The background for this question is related to INSPIRE-MIF/gp-data-service-linking-simplification#68. Specifically, what preferred labels should be included on this page: https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue, the short ones (e.g. wms) or the long one (e.g. OGC Web Map Service).

[rob-metalinkage]

This turns out to be due to other information clashing with the authoritative definitions - and the UI choosing arbitrary values for something that is expected to be single value.

@avillar - we will need to add a validation step to catch this - this may need to be a post-deployment step that operates on the graph as a whole as it can be tested in the resource pipeline if the target deployment is known and accessible, which is not known at the validation phase.

@ghobona - this was an issue caused by the standards baseline (standards.ttl) vocabulary - I have moved this to the incubation directory for remediation and removed from the servers.

we will confirm the concept-level SKOS works as required.

another issue is that the source material does not have a definition per se: just a comment
rdfs:comment "This is the non-version specific service type. It should be used to designate a service that will perform version negotiation. Specific versions may also be used to designate the supported versions"@en;
.

hence the label is used as the best definition available for the preferred definition .

We will need to pull the skos:definitions out of the standards collection view and add to the object definitions.

[heidivanparys]

@rob-metalinkage It is not only about the definitions but also about the preferred labels. For example, when I look at https://github.com/opengeospatial/NamingAuthority/blob/master/definitions/conceptschemes/servicetype.ttl and https://github.com/opengeospatial/NamingAuthority/blob/master/definitions/conceptschemes/entailed/serviceType.ttl (I don't know what is the difference between those two files), I can see that http://www.opengis.net/def/serviceType/ogc/wms has two preferred labels:

• OGC Web Map Service
• OGC Web Map Service Versions

The same applies to some of the other service types.

What the INSPIRE community needs to know, is the correct preferred labels for the service types, because these are duplicated in the INSPIRE registry at https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue, and this is blocking INSPIRE-MIF/gp-data-service-linking-simplification#68.

In INSPIRE-MIF/gp-data-service-linking-simplification#68, it was also suggested that the correct preferred label for e.g. http://www.opengis.net/def/serviceType/ogc/wms is “wms”, and not “OGC Web Map Service” (based on what is shown at http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/serviceType/ogc/wms), it would be good to have that clarified as well.

• http://www.opengis.net/def/serviceType/ogc/csw
• http://www.opengis.net/def/serviceType/ogc/sos
• http://www.opengis.net/def/serviceType/ogc/wcs
• http://www.opengis.net/def/serviceType/ogc/wfs
• http://www.opengis.net/def/serviceType/ogc/wms
• http://www.opengis.net/def/serviceType/ogc/wmts

[avillar]

@ heidivanparys, there is a subtle difference between the two resources above:

• http://www.opengis.net/def/serviceType/ogc/wms is a Concept with label "OGC Web Map Service".
• http://www.opengis.net/def/serviceType/ogc/wms/ (note the trailing slash) is a Collection with label "OGC Web Map Service Versions".

The /entailed/ version contains the original data, plus some inferred new properties and relationships. It also adds a SKOS Collection, usually by appending a trailing slash to the ConceptScheme that it is built from. The rationale for this predates me, but you can see the difference if you browse to the URL with and without the trailing slash.

[ghobona]

@heidivanparys

The INSPIRE use case involves referencing the concept of a WMS in a code from the INSPIRE code lists.

http://www.opengis.net/def/serviceType/ogc/wms/ is a collection of concepts representing the different versions of WMS.

http://www.opengis.net/def/serviceType/ogc/wms is the concept of the WMS standard itself.

Therefore, it would be advisable for the INSPIRE code list to reference http://www.opengis.net/def/serviceType/ogc/wms.

[ghobona]

@avillar Please look into implementing a validation mechanism for identifying any concepts that have multiple skos:definitions and skos:prefLabels. The mechanism should generate a report (triggered by a GitHub Action) and saved in the repo. It should read directly from the RDF4J Workbench and not Django CMS.