CaLAThe - Rendering of 'in scheme' information

[estubkjaer]

CaLAThe version 4 organises content into two schemes: CaLAThe with pref label 'CaLAThe 4.0' and CaLATheCodeList with prefLabel 'CaLAThe 4.0 - Code lists'

Presently, the information provided on these schemes is not correct: For concepts in both concept schemes, both concept schemes are mentioned Examples: Boundary https://defs.opengis.net/elda-common/ogc-def/resource?uri=https://www.opengis.net/def/CaLAThe/4.0/Boundary&_format=html Professional https://defs.opengis.net/elda-common/ogc-def/resource?uri=https://www.opengis.net/def/CaLAThe/4.0/Professional&_format=html siteMark https://defs.opengis.net/elda-common/ogc-def/resource?uri=https://www.opengis.net/def/CaLATheCodeList/4.0/siteMark&_format=html

Mention is made that some concepts appear both in concept scheme CaLAThe ('CaLAThe proper') and concept scheme CaLAThe code lists, Example: Boundary mark, which is both narrower of Survey mark of CaLAThe proper, and also value of code list SurveyMonumentType https://defs.opengis.net/elda-common/ogc-def/resource?uri=https://www.opengis.net/def/CaLAThe/4.0/BoundaryMark&_format=html

Background:

Motivation for two schemes: Basically, the code list structure is hierarchical. This might suggest that skos:Collection is applied, and not skos:ConceptScheme. However, LandInfra could specify a number of values in terms of /codeList URI [0,1], as specified for code list SurveyMonumentType, which would break the strict hierarchical structure. Therefore, to keep flexibility, skos:ConceptScheme is chosen.

Motivation for the use of two schemes: The code list names are all in the CaLATheCodeListScheme, but the code list values are looked for in the CaLAThe scheme, perhaps added, if considered relevant for the CaLAThe user and meaningful in its own right. For example, in code list LandParcelState, CarrierParcel is included in CaLAThe, because it carries a Condominium unit, and MainParcel in some juristictions indicates a specific parcel among several.

[rob-metalinkage]

The current infrastructure is geared around a publishing paradigm of ConceptSchemes as a unit of governance - so the co-existence of a Concept that exists in two registers makes sense only if the governance of those two registers takes this into account. I believe the case describe here does fit under this paradigm, and is consistent with the SKOS model, so there is no logical barrier to realising this.

It will take some coding - setting up test cases etc.

There is a workaround available however - supply an extra file with statements linking the two which can be manually added to the RDF store.

Is there any information on which elements need to be in two schemes?

the file I have access to (https://github.com/opengeospatial/NamingAuthority/blob/master/definitions/conceptschemes/CaLAThe.ttl)

has both ConceptSchemes defined - but only shows one concept scheme linked to "Boundary Mark" in this case..

https://www.opengis.net/def/CaLAThe/4.0/BoundaryMark rdf:type skos:Concept ; skos:prefLabel "Boundary mark"@en ; skos:definition "Physical object which by its form defines a point on the surface of the Earth, which is stably located, and which is recorded in a statement. It may carry a symbol of authority, which communicates its purpose, e.g. marking of the legal boundary between two Land parcels according to jurisdiction-specific provisions (Source: OGC LandInfra, 4.8.16; 7.10.5.1).\n"@en ; skos:changeNote "Established with version 1. Definition with version 3."@en ; skos:inScheme https://www.opengis.net/def/CaLAThe ; skos:altLabel "Boundary monument"@en ;

If this file is updated I can extract the dual citizens and inject the statements into the Def server and everything should work as required.

[dr-shorthair]

Having a unit-of-governance makes sense to me. skos:ConceptScheme is a reasonable choice. (In the LDR it was reg:Register - these containers are convenient choices, not inevitable.)

Then if a unit-of-thought (skos:Concept, rdfs:Class, etc) needs to be visible in in more than one location, then perhaps skos:Collection is the logical option?

[estubkjaer]

Observations:

1. In the file https://github.com/opengeospatial/NamingAuthority/blob/master/definitions/conceptschemes/CaLAThe.ttl line 1-110 is edited, relative to the SKOS .rdf file submitted (No problem, just noted fact) 110 - 2562 is the CaLAThe part 2562 - 3410 is the code list part The subsequent list of labels (to line 4512) is added to the submitted.

2. In the introduction line 1-110 skos:Member and skos:Collection are applied, establishing a CaLAThe <- CaLAThe/4.0/ <- CaLAThe/4.0/ all concepts listed as members (I assume) . Similarly, we have CaLATheCodeList/ with skos:member https://www.opengis.net/def/CaLATheCodeList/4.0/, and all codelist names and code list values (I assume)

It seems that it is http://www.opengis.net/def/metamodel/ogc-na/collectionView which refers to both https://www.opengis.net/def/CaLAThe/; (line 26) and https://www.opengis.net/def/CaLATheCodeList/; (line 92)

Comments: The fact that some concepts appear both as CaLAThe concepts and as CaLATheCodeList values seems not to conflict with the chosen collection - member formalism. The concepts Boundary and Professional are only in the CaLAThe concept scheme, and siteMark only in CaLATheCodeList scheme. This is the problem. The next update of CaLAThe could, referring to https://www.w3.org/TR/skos-reference/#L3588, introduce CaLATheCodeList as a nested collection.

[rob-metalinkage]

Have assigned to Gobe to review history of the TTL file - but it looks to me as if its a post-inferencing dump from the defs server. (commit a57b7582cb4b6984657bfffb5a3df826d6f23edb)

FYI The top level collection view is generated automatically if missing, from any collections at the root of collection hierarchies. Might need to run some tests that it works as expected if you manually create a preferred structure.

so is the sum totoal of things needing fixing is the additional scheme declaration for those three concepts: Boundary,Professional, siteMark

so I could add:

https://www.opengis.net/def/CaLAThe/4.0/Boundary skos:inScheme https://www.opengis.net/def/CaLATheCodeList . https://www.opengis.net/def/CaLAThe/4.0/Professional skos:inScheme https://www.opengis.net/def/CaLATheCodeList . https://www.opengis.net/def/CaLATheCodeList/4.0/siteMark skos:inScheme https://www.opengis.net/def/CaLAThe

to resolve this?

[estubkjaer]

The additional scheme declarations will in no way solve the problem. The three examples indicate a general problem, namely that for each concept two schemes are mentioned. For example Boundary https://defs.opengis.net/elda-common/ogc-def/resource?uri=https://www.opengis.net/def/CaLAThe/4.0/Boundary&_format=html you read in section 'in scheme' the following:

ca lAThe
ca lAThe code list

which link to CaLAThe and to CaLATheCodeList, respectively. This is wrong, as Boundary is in scheme CaLAThe only.

And this holds for all the other about 250 terms of CaLAThe.

And for the about 110 code list names and values only CaLATheCodeList should be mentioned in the 'in scheme' section.

[rob-metalinkage]

with the new UI only one scheme is rendered

http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/CaLAThe/4.0/Boundary

can we review this is still active?

[estubkjaer]

Rob,

Frankly, I don’t understand the question. The rendering looks ok (Except that I find the box Alternate profiles unneeded when you have the seeAlso link ; also, ‘Preferred level’ ‘Change note’ should be rendered on one line)

Erik

From: Rob Atkinson @.> Sent: 20. april 2021 08:52 To: opengeospatial/NamingAuthority @.> Cc: Erik Stubkjær @.>; Author @.> Subject: Re: [opengeospatial/NamingAuthority] CaLAThe - Rendering of 'in scheme' information (#41)

with the new UI only one scheme is rendered

http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/CaLAThe/4.0/Boundary

can we review this is still active?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/NamingAuthority/issues/41#issuecomment-823022053, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOPCPWO4FMV34LJ555CKOETTJUQCBANCNFSM4L4HY6PA.

[rob-metalinkage]

closing if its OK. UI improvements to come.

[ErikStubkjaer41]

I see an option: The CaLAThe Concept Scheme could include a 'CaLAThe-interpretation of codelist' as they are now rendered.
CaLAThe - Codelists - definitions, and CaLAThe 4.0 - Codelists should then be removed, and replaced by code lists recorded within the respective standards. For OGC standards likely together with the definitions (section 4) of the concerned standard. No objections to closing #41

[rob-metalinkage]

I'm all for modularising according to governance realities - codelists for each standard as separate ConceptSchemes. then we can add Collections in CaLAThe to index all these and make them discoverable, or whatever else the underlying requirement is. Could we write a Use Case for this, with explict pre- and post-conditions for a User discovering and/or accessing these terms and what they are seeking to do?

[ErikStubkjaer41]

I think, Volkan and I could work on the Use Case idea, and check it with our cadastral surveying colleagues

[ghobona]

@ErikStubkjaer41 This issue was originally about the previous UI of the Definitions Server. Now that we are using the new vocprez-based UI, may we close the issue?

[ErikStubkjaer41]

Agree

[ghobona]

Thanks @ErikStubkjaer41 !