- Back to Avalon Collaboration Page
- Entry Points to Learning About ISO 15926
- Case Studies
- Principles of Interoperability
- Building a Business Case
- Discovering the Right Class
- TC 184 SC 4 WG 3
- Using the RDS/WIP (RDL Façade)
- POSC/CAESER RDS
- Mapping to ISO 15926-4
- Using Templates
- Diagnostic Page
Discovering the Right Class in ISO 15926
Status of this document: Working Draft
This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will need a login to post in the forum.
A typical ISO 15926 class search starts with a label search. The following class attributes should be used to confirm that you do have the right class. Note: there is no specific order in using these attributes. However, "Description/Definition" and "Entity Type" play a dominant role in filtering selections. "Label" tends to be the most ambiguous and yet is the often used exclusively with first time users of the RDL.
- Label -- this is the starting point for searches if only because today this is all you can search.
- Description/Definition -- sometimes this is missing or almost the same as the label. A good description is very helpful in clarifying the meaning of the RDL class. Search should be expanded to include the description as a future enhancement.
- Note -- some RDL classes have a Note which can provide additional context. Sometimes this is just a supplemental Description.
- Entity Type -- it is important to check that the class found is of the correct level and type.
- Level -- the entity type must be the correct "level", i.e. individual, class, or class of class. Most commonly a class is being searched for, and inexperienced users will find a class of class and not realize that it is not what they need. For example INSTRUMENT CLASS. By convention classes of class normally have the word CLASS at the end of the label so that is a good first check.
- Type -- if the RDL item is the correct level you should check that the type is correct. Unfortunately this requires a basic understanding of the Part 2 entity types. Sometimes the label and description seem like a perfect match but the type is not at all what is needed. For example, TAG NAME has a label, description, and note that indicate it is what we want as a class representing component tags. However, the entity type is DocumentDefinition? so it can’t be used for that purpose.
- Taxonomy -- a class should have specialization parents and children that make sense. The tools make it easy to browse this hierarchy. Browsing the taxonomy is also useful when a label search does not locate the desired result. You may be able to find a parent or child class and navigate to the desired class from there, or at least better understand what is there. Unfortunately sometimes the taxonomy is incomplete, or at least not what one would expect.
- Classifications -- membership in a class could in some cases be a useful criterion. For example you might want to find classes with a particular provenance or certification. Unfortunately the current tools only show "upwards" classification, they show the classes that a class is a member of, but they don’t show the members of a class. This would be a simple enhancement.
- Templates -- specialized templates are very useful for class identification and navigation. Right now this is of limited use because there are few templates in the reference data, but it should become increasingly valuable. But this does require the use of specialized templates or some alternate way of defining OIMs.
Acknowledgement: Thanks to Daris Kanga for the information on this page.