Closed nicholascar closed 7 years ago
There is no skos:members property defined in the SKOS vocabulary (1). However there is a skos:memberList which is probably what was intended (2).
Nevertheless, it is certainly easier to process member/Concept than memberList/Concept - the SPARQL around 'collections' is not very easy to unwind (3).
(1) https://www.w3.org/TR/skos-reference (2) https://www.w3.org/TR/skos-reference/#memberList (3) https://www.w3.org/TR/sparql11-query/#collections
True, there is no skos:members property defined and I also feel that skos:memberList would make things more complicated. However this change requires a corrigendum in the ISO 19150-2 to confirm it. ISO/TC 211/GOM will initiate this work and will also propagate this change to all other codelists to be consistent and compliant with skos.
The request came from Geoscience Australia who are deploying operational systems using this ontology and had hit a blocker. It is a clear error in the repository. OGC adopts a policy whereby the repo takes precedence, because of operational requirements like this. The iso repo will become irrelevant if bugs cannot be fixed in a timely manner. The months to years corrigendum cycle won't work. Else we need another trusted repo which can be maintained to meet user needs.
Agree! I believe we can do this in parallel, i.e. fix the repository while we are working on the standard.
OK - Good you agree that the process has to be able to deal with this. Thanks.
The current construction of SKOS Collections in iso19160-1Address.owl seems to be incorrect. There are Collection classes containing a "members" class containing Concept classes. The correct SKOS formulation is a Collection class containing "member" classes. This is what I have changed. As a result, the file now is valid RDF (tested using the Python rdflib module) so I can now convert iso19160-1Address.owl to other RDF formats like turtle.