ISO-TC211 / GOM

Group for Ontology Management
23 stars 5 forks source link

replaced skos Collection's members/Concept*N with member*N #5

Closed nicholascar closed 7 years ago

nicholascar commented 7 years ago

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.

dr-shorthair commented 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

BrodeurJS commented 7 years ago

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.

dr-shorthair commented 7 years ago

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.

BrodeurJS commented 7 years ago

Agree! I believe we can do this in parallel, i.e. fix the repository while we are working on the standard.

dr-shorthair commented 7 years ago

OK - Good you agree that the process has to be able to deal with this. Thanks.