The seven CaLAThe topConcepts return HTTP 404 errors

[ghobona]

The seven CaLAThe topConcepts presented at https://www.opengis.net/def/CaLAThe return ‘404 Resource Not Found’ Reason is, I think, that the URI, e.g. https://www.opengis.net/def/CaLAThe/Information does not account for the version, because https://www.opengis.net/def/CaLAThe/4.0/Information provides the relevant information.

Issue discovered by @estubkjaer

[ghobona]

This has been resolved by linking the generic concepts to the CaLAThe 4.0 concepts through a skos:exactMatch

https://www.opengis.net/def/CaLAThe

[rob-metalinkage]

Hi Gobe - can you let me know if you are changing defs server content - and how you are doing it? Am republishing content with some cleaned up metadata for the new profiles support and I dont want to lose any tweaks.

[rob-metalinkage]

Reopened until tested migration to server update is working OK.

[rob-metalinkage]

OK - I have republished - and updated the defs server to use the new content versions : and the improved publishing pipeline automatically detected the top concepts - and jumps directly to the version. I think this suits. Please close on review

[ghobona]

@rob-metalinkage I bypass the Definitions Server Admin client and insert the content directly through RDF4J Workbench. I need this flexibility because the Definitions Server Admin client has some apparent bugs when handling several concept schemes in the same file.

[ghobona]

@rob-metalinkage I have just tried out the updated Definitions Server Admin client and confirmed that it does support publishing multiple concept schemes in a single file. Great job!

[estubkjaer]

@ghobona @rob-metalinkage

Agree that original problem was solved, thanks, but reopened because the latest change generated unwanted concequences. Example: Activity in scheme ca lAThe (should be CaLAThe) Wrong to mention 'ca lAThe code list' here, because Activity is not in concept scheme ca lAThe code list

narrower Exchange, Transfer ok, but 'property formation' ought to be 'Property formation'

The idea of rendering of transitives has to be reconsidered, because 'Amalgamation' is narrower of 'Property formation', while the following 'Conveyance' is narrower of 'Exchange'

Next 'Exchange' has been mentioned already

Generally, it seems that all narrower transitive of Activity is rendered in alphabetical order, without indication of level. Options: 1 All transitives are avoided

2. Transitives are rendered with in-between terms/concepts
3. Option 2 + user may indicate depth of levels

Next example: Property formation broader: Activity ok, but why then narrower: Property formation and worse: narrower transitive in scheme CaLAThe (not ca lAThe) and definitively not in code list scheme

change of property unit type should be Change ... - Similar Parcel est.. and several other

[rob-metalinkage]

Hi will look into these issues.

The name munging is an unfortunate behaviour of the code based used - I'm looking to replace it because that part is not configurable. It may have been fixed by some explicit label creation that got missed, but should have been restored now.

The longer term plan would be a new renderer that looks at profiles - and we can define profiles that choose different subsets of properties and different property chain depth traversals to give more flexibility.

Can you provide URLs for the examples you are citing and we'll see if we can come up with quick fixes,

Cheers Rob

On Thu, 2 Apr 2020 at 01:36, estubkjaer notifications@github.com wrote:

Agree, that original problem was solved, thanks, but the latest change generated unwanted concequences. Example: Activity in scheme ca lAThe (should be CaLAThe) Wrong to mention 'ca lAThe code list' here, because Activity is not in concept scheme ca lAThe code list

narrower Exchange, Transfer ok, but 'property formation' ought to be 'Property formation'

The idea of rendering of transitives has to be reconsidered, because 'Amalgamation' is narrower of 'Property formation', while the following 'Conveyance' is narrower of 'Exchange'

Next 'Exchange' has been mentioned already

Generally, it seems that all narrower transitive of Activity is rendered in alphabetical order, without indication of level. Options: 1 All transitives are avoided

2. Transitives are rendered with in-between terms/concepts
3. Option 2 + user may indicate depth of levels

Next example: Property formation broader: Activity ok, but why then narrower: Property formation and worse: narrower transitive in scheme CaLAThe (not ca lAThe) and definitively not in code list scheme

change of property unit type should be Change ... - Similar Parcel est.. and several other

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/NamingAuthority/issues/22#issuecomment-607287587, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCHOYMJVQE4HLZVKLK64M3RKNGQNANCNFSM4KSJZOWA .

[estubkjaer]

Hi, Activity https://www.opengis.net/def/CaLAThe/4.0/Activity Property formation https://www.opengis.net/def/CaLAThe/4.0/PropertyFormation

At http://cadastralvocabulary.org select Graphical overview , next 2. CaLAThe-Activity to see a hierarchy of ‘Activity’ terms

Thanks Erik

From: Rob Atkinson notifications@github.com Sent: 2. april 2020 00:08 To: opengeospatial/NamingAuthority NamingAuthority@noreply.github.com Cc: Erik Stubkjær est@plan.aau.dk; State change state_change@noreply.github.com Subject: Re: [opengeospatial/NamingAuthority] The seven CaLAThe topConcepts return HTTP 404 errors (#22)

Hi will look into these issues.

The name munging is an unfortunate behaviour of the code based used - I'm looking to replace it because that part is not configurable. It may have been fixed by some explicit label creation that got missed, but should have been restored now.

The longer term plan would be a new renderer that looks at profiles - and we can define profiles that choose different subsets of properties and different property chain depth traversals to give more flexibility.

Can you provide URLs for the examples you are citing and we'll see if we can come up with quick fixes,

Cheers Rob

On Thu, 2 Apr 2020 at 01:36, estubkjaer notifications@github.com wrote:

Agree, that original problem was solved, thanks, but the latest change generated unwanted concequences. Example: Activity in scheme ca lAThe (should be CaLAThe) Wrong to mention 'ca lAThe code list' here, because Activity is not in concept scheme ca lAThe code list

narrower Exchange, Transfer ok, but 'property formation' ought to be 'Property formation'

The idea of rendering of transitives has to be reconsidered, because 'Amalgamation' is narrower of 'Property formation', while the following 'Conveyance' is narrower of 'Exchange'

Next 'Exchange' has been mentioned already

Generally, it seems that all narrower transitive of Activity is rendered in alphabetical order, without indication of level. Options: 1 All transitives are avoided

2. Transitives are rendered with in-between terms/concepts
3. Option 2 + user may indicate depth of levels

Next example: Property formation broader: Activity ok, but why then narrower: Property formation and worse: narrower transitive in scheme CaLAThe (not ca lAThe) and definitively not in code list scheme

change of property unit type should be Change ... - Similar Parcel est.. and several other

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/NamingAuthority/issues/22#issuecomment-607287587, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCHOYMJVQE4HLZVKLK64M3RKNGQNANCNFSM4KSJZOWA .

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/NamingAuthority/issues/22#issuecomment-607514163, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOPCPWNGBVFRGELKKVIDQXLRKO3NRANCNFSM4KSJZOWA.

[ghobona]

Since the original issue has been solved, I would like to close this thread.

@estubkjaer Could you please create separate new issues for each of the problems identified in your comment https://github.com/opengeospatial/NamingAuthority/issues/22#issuecomment-607287587 ?

This will help us to track the discussion better.