dcterms:conformsTo in Example 58 eea-csw.ttl

[smrgeoinfo]

currently have a:EEA-CSW-Endpoint dcterms:conformsTo <http://www.opengis.net/def/serviceType/ogc/csw> ;

but that URI resolves to a non-version specific service type concept, not a specification. It seems that a common search scenario would be for a service endpoint that implements a particular version (and maybe event a particular profile) of a service, so I'd suggest this should be

dcterms:conformsTo <http://www.opengis.net/doc/IS/cat/cws/3.0> ;

which is the identifier for OGC® Catalogue Services 3.0 Specification - HTTP Protocol Binding

the URI for the non-version specific service type would be better included as dcterms:type <http://www.opengis.net/def/serviceType/ogc/csw> ;

[agbeltran]

@smrgeoinfo I wanted to double-check: it seems that http://www.opengis.net/doc/IS/cat/cws/3.0 should redirect to http://docs.opengeospatial.org/is/12-176r7/12-176r7.html but it is not, do you what the problem could be?

otherwise, should we be using http://docs.opengeospatial.org/is/12-176r7/12-176r7.html instead for the dcterms:conformsTo statement?

[bertvannuffelen]

To facilitate our users to set the dct:conformsTo to a cannonical list of technical protocols, the Flemish DCAT profile is creating a codelist. See https://github.com/Informatievlaanderen/OSLOthema-metadataVoorServices/blob/master/codelijsten/protocol.ttl

The above challenge "which URI/URL" to use is not something you want to bring to the day-to-day editor of a dataservice. This codelist provides a pivot which allows any user of the metadata to find in the end the right specification to read as the codelist will be published using PURIs.

This is a practical solution to the discussion. In the end the list of protocols is endless, but this is a collection which is aimed to form a basis of commonly used protocols, and is open for collaboration with the community.

[rob-metalinkage]

For more recent OGC specifications you should refer to the "conformance class" with its canonical uri .. this also allows finer grained semantics and validation. We should explore how OGC might publish a profile or consider vocabulary set support the Flemish one could utilise and extend. Stay tuned. I will consult internally in OGC about the Use Case here.

[davebrowning]

Project/Milestone modified.

Explanation: As DCAT v3 moves through review and hopefully ratification, we want to make sure that open issues and feedback that have yet to be completely addressed are properly recorded and tagged/assigned in github to both clarify their status and to help review and prioritise as a source of improvements and new requirements in future DCAT versions

[rob-metalinkage]

Actually, there is an issue we are looking at fixing.. the OGC document may define multiple "conformanceClasses" that are the specifications that things actually "conformTo" - so the best statement would be one that references such a conformance class. (OGC still needs to make a call whether specifications that pre-date the identification of formal conformance classes should declare the document URL as a sort of proxy conformanceClass or mint a register of conformanceClass objects that reference these legacy specifications.)

For clarity, a up-to-date reference using OGC API might be better... as in this example:

https://docs.opengeospatial.org/is/17-069r3/17-069r3.html#_declaration_of_conformance_classes

NB OGC is about to charter a GeoDCAT profile - and I think it may make sense to define an GeoDCAT-OGC sub-profile that constrains conformsTo to include a reference to an OGC conformanceClass declaration.

[bertvannuffelen]

@rob-metalinkage I think we have to be careful with the formulation of such restrictions.

What if the dataset I am describing also from another profile get the requirement to specify a conformity. E.g. in the EU HVD regulation there might be the requirement to a specific reference that is outside the OGC space.

If you want to restrict codelists then the best is to create a specific subproperty with that constraint attached. (btw this a general remark on anything that has to do with properties that would be scoped by codelists.)

[rob-metalinkage]

its an example - conformsTo can have multiple values - i dont see the problem nor need to restrict (OGC 's own profile can do that restriction if it wants, not DCAT - thats the nature of profiles

and the restriction can be oneOf not allOf

[smrgeoinfo]

I agree that the value of conformsTo would most usefully be a conformance class, but there are not many specifications that define conformance classes. Seems that definition of a controlled vocabulary for specifying conformance would need to be part of a profile definition. @rob-metalinkage suggestion to use multiple values for various possibilities is workable.

there was an effort to develop a community registry for identifiers to use in ISO metadata that Tom Kralidis/OSGEO started in 2014 https://github.com/OSGeo/Cat-Interop

[rob-metalinkage]

in case you havent seen it sounds like that group should sync up with the GeoDCAT work

https://www.ogc.org/standards/requests/262?utm_source=phplist904&utm_medium=email&utm_content=HTML&utm_campaign=OGC+to+form+GeoDCAT+Standards+Working+Group%3B+Public+Comment+sought+on+Draft+Charter

[bertvannuffelen]

its an example - conformsTo can have multiple values - i dont see the problem nor need to restrict (OGC 's own profile can do that restriction if it wants, not DCAT - thats the nature of profiles

and the restriction can be oneOf not allOf

I agree that a profile could make it own decisions, but it also may do it in such a way that it blocks usage of that profile.

My example is that I have to comply to DCAT-AP HVD profile AND GeoDCAT profile. The way how the constraints are formulated do matter extremely here.

_:d1 dct:conformsTo ogc:a.
_:d1 dct:conformsTo iso:b.

violates the expression that the values must be from the OGC codelist Instead it should be e.g. formulated as such as the recommended codelist is OGC codelist, but others are allowed (a more open formulation.)

This is extremely important for those specifications that intend to be an intermediate layer between a real profile that is being used in a system and one that is providing guidelines for a community. In DCAT-AP (an intermediate layer) this is a constant attention point, sometimes successful, sometimes it can be improved. In my opion OGC:GeoDCAT is also layer in between, and not a final profile that systems are going to use. And therefore I draw attention to these formulations.