You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BUFR code tables 0 20 004 and 0 20 005, Past Weather (1) and (2) are expressed in the printed manuals as hierarchical lists.
The UKGovLD software now supports a tree view of hierarchical lists, which is triggered by some annotations on the Register itself. One annotation is need to identify which are the root members, and one to define the path used to get from parent to child entity.
These are independent of the membership property used, and need not use
SKOS.
So for a skos:ConceptScheme you would indeed typically have skos:inScheme as the (inverse) membership property, skos:topConceptOf as the property which indicates a root concept and skos:narrower|^skos:broader as the path from concept to child concept.
One issue remains in that for 0 20 004 and 0 20 005, only the leaf nodes are valid terms.
The non-leaf nodes could be marked with status invalid (noting that this would make them disappear from lists for users who are not logged in; perhaps just best to mark them as deprecated? ... or some other special status?). And to include an "in-your-face" comment about not using them in data?
Alternatively, one could set up an alternative register for the ConceptScheme which includes the non-leaf nodes - but then confusion will arise as to why there are two registers for the same thing.
More analysis required; but the single concept scheme with deprecated status for non-leaf nodes seems like the best compromise.
The text was updated successfully, but these errors were encountered:
BUFR code tables 0 20 004 and 0 20 005, Past Weather (1) and (2) are expressed in the printed manuals as hierarchical lists.
The UKGovLD software now supports a tree view of hierarchical lists, which is triggered by some annotations on the Register itself. One annotation is need to identify which are the root members, and one to define the path used to get from parent to child entity.
These are independent of the membership property used, and need not use
SKOS.
So for a
skos:ConceptScheme
you would indeed typically haveskos:inScheme
as the (inverse) membership property,skos:topConceptOf
as the property which indicates a root concept andskos:narrower|^skos:broader
as the path from concept to child concept.One issue remains in that for 0 20 004 and 0 20 005, only the leaf nodes are valid terms.
The non-leaf nodes could be marked with status invalid (noting that this would make them disappear from lists for users who are not logged in; perhaps just best to mark them as deprecated? ... or some other special status?). And to include an "in-your-face" comment about not using them in data?
Alternatively, one could set up an alternative register for the ConceptScheme which includes the non-leaf nodes - but then confusion will arise as to why there are two registers for the same thing.
More analysis required; but the single concept scheme with deprecated status for non-leaf nodes seems like the best compromise.
The text was updated successfully, but these errors were encountered: