To Register Properties, see [this page]
The Open Metadata Registry uses the [Simple Knowledge Organisation System (SKOS)] as the basis for building concept vocabularies.
Step 3b: Register Concept Vocabularies
Building a set of concepts starts with a description of the vocabulary as a collective whole. Once the Agent has been registered, a new vocabulary form can be invoked by clicking on the (Add) link showing after the Vocabularies link on the right hand browse menu (note that the (Add) portion will not appear if the user is not logged in, and clicking on the Vocabularies link will produce a list of already registered Vocabularies). A basic template allowing a description of an Vocabulary will appear, divided into sections. In general, users should tab through the form to take best advantage of the Registry defaults.
- User is provided with a drop-down list of all the agents for which the user is enabled to act. The user must choose one to be the owner of the vocabulary.
- The name is a human-readable descriptive label for the element set as a whole. This text will be displayed in lists of vocabularies and should be optimized for a human reader, preferably without combined words or camel case.
- A non-Registry URL that contains more information about this vocabulary. This information is optional, but useful, if the vocabulary already has a presence on the web.
- A note about this element set. This is optional, and may contain any information that may be relevant to users of the vocabulary.
- In this space may be entered free text tags identifying communities of practice for which this element set is intended. At present, it is not possible to use these tags to search for related vocabularies, but this functionality will be added later.
- The drop down menu supplies a status that will serve as a default status for the properties of this element set as they are created. Once a vocabulary is registered, the statuses of individual properties must be changed individually--a change made to the vocabulary as a whole will not proliferate throughout the vocabulary. This allows each property to be maintained separately as part of a vocabulary development process.
- The drop down menu supplies a default language for the properties of this element set as the properties are created. When desired, individual property statements can be overridden with a non-default language, providing the capability for a multilingual property vocabulary.
- Base Domain
- The root of all URIs for this vocabulary and its terms. By default the Registry assigns the Registry domain, but this may be overridden by another Base Domain typed over the default by the Owner of this vocabulary.
- The user provides here unique token representing this particular vocabulary. This will be used as the prefix identifying this URI in RDF or a qname in XML. This name should be terse and contain no spaces. Camel case is preferred.
- The URI assigned to this element set. By default this will be a concatenation of the Registry default domain and the vocabulary Name. If a domain other than the Registry default is desired for the Vocabulary and its individual properties, the desired namespace must be entered here manually, overriding the normal Registry default. The URI designated here will then become the default for the registration of individual properties later on in the workflow.
When the desired parts of the form are filled in, the user should click on the SAVE button at the bottom of the page.
Step 4a: Register Individual Concepts
Once the top level vocabulary description is saved, it will appear with several tabs above the description: Detail (which displays the full description for the concept vocabulary), Concepts (which displays in list form all the concepts in the vocabulary), History (which gives a full history of changes made), Versions (which links to any defined versions of the vocabulary), and Maintainers (which gives a full list of those approved to manage the vocabulary, and their roles). To add Concepts to the vocabulary, click on the Concepts tab: if no elements are yet available in that vocabulary, the Registry will respond with that message, and below it will be a link to create an Element. If that link is invoked, a form will be returned:
The form includes the following:
- Preferred Label
- This is the SKOS:prefLabel property of this Concept and is required for every Concept. This is intended to be a human-friendly label for this property and should be optimized for human viewing--it may have spaces. Combined words and camel case are not recommended.
- The URI is generated by the system, based on the default supplied in the vocabulary description created earlier, using a sequential number assigned by the the system to create a unique URI. Owners who prefer a non-numeric extension may override the default by typing in their preferred name.
- Top Concept?
- A check box is provided to allow identification of concepts at the top of a hierarchy of relationships.
- This is the overall status of this Concept. Individual concepts in this property may have different statuses.
- This is the default language for all concepts of this vocabulary, which will be extended to each concept. If a language other than the default are desired for particular concepts, the default language can be overridden by editing the Language at the statement level.
Additional concepts needed for the vocabulary can be added by repeating the process.
Relationships between concepts should be added after the initial registration of concepts themselves have been completed. The Registry expects that when a relationship is asserted, that both levels are already present. When building a relationships between concepts, a drop down list presents all concepts available in the vocabulary, ensuring that only appropriate relationships are made, and ensures that relationships are reciprocal.
Step 5a: Editing or Extending Existing Concepts
When a set of concepts are initially registered, a number of maintenance actions are available to manage the vocabulary. Data can be edited (corrections, additions of text to definitions, deletions, etc.) or extended (statements added, relationships added).
Starting with a list of existing concepts, either click the edit button to the right of the concept, or go to the detail for the concept itself by clicking on the name or URL from the list.
Choose either the the edit button from the bottom of the display. (If the edit button does not appear on the list or the detail display for the property, either the user is not signed in, or the user is not authorized to edit this particular element set.)
Once the edit screen for the concept is displayed, any visible data can be modified and any empty text boxes can be filled in. Note that when displaying the detail for a class or property, information on subclass or subproperty relationships does not display in this view and cannot be added or edited from the detail edit screen. See the instructions for Extending Existing Elements/Properties to add or edit those relationships.
Extending Existing Elements/Properties
An alternate approach to editing, which allows access to all the properties at a statement level (including subclass and subproperty relationships), starts from the list of Elements. Clicking on the element to be edited, and, when the detail is displayed, clicking on the Statements tab, provides a list of all property statements, with available actions in the right hand column.
From this view, the actions available for each statement are visible in the right hand column. Some statements can be edited, others can be deleted, and the defaults (which show no actions in the right hand column) show no actions; they must be changed using the detail edit screen shown above. At the bottom of the display, a button to invoke a form to add new statements can be clicked. This is one method available to add new hasSubproperty relationships from the property itself (the other method is to add a new 'parent' property to a subproperty). Because element properties can have multiple relationships, care should be taken to ensure that reciprocals are correct. Because existing relationships cannot be edited directly via the detail editing screen, relationships that require change must be deleted first, then added back in their changed version.
Adding Property statements for elements identified as classes is more limited, because classes must have 'one-to-one' hierarchies. Therefore, the drop down list for element properties includes:
While the drop down list for elements identified as classes includes: