The Data View: Editing SKOS Thesauri
Intro
This section describes the thesauri editing functionalities available in VocBench. We will go through the set of functionalities as they appear in the various elements of the user interface.
The Various Sections in SKOS Projects
SKOS Projects offer 5 sections for managing different kind of resources. We have already described the Class and Property sections in the manual page on OWL Editing, so here we will discuss the three other sections peculiar to thesauri.
When editing a SKOS thesaurus, the landing page for the Data View is the Concept Section. When opening a new project for the first time, VB will inform the user (through the question mark on the yellow triangle in figure below) that one or more schemes have to be selected, in order to show their related concept trees.
The Scheme Section
The Scheme Section (as of all the data section) is composed of two main areas: the structure on the left, and the resource view on the right. However, differently from other resources, the structure page offers a simple list, and not a tree (or, better, in a forest) as skos:ConceptSchemes have no taxonomic relation among them. Concept schemes provide containers for concepts in a thesaurus. Depending on the literature, it is also possible to say that concept schemes identify different thesauri in a same dataset. Whatever the terminology, the objective of concept schemes is to allow different views on a shared pool of concepts.
The Scheme section allows to create and destroy skos concept schemes. When the usual + button is clicked, a form allows the user to prompt the concept scheme information. The form is composed of the following elements:
- Label: when a concept scheme is created, a label will be attached to it. The label will be generated with the prompted text and with a structure following the lexicalization model specified for the project (rdfs:label, skos or skos-xl labels, using preferred labels for the latter two models)
- URI: the URI for the scheme can be manually defined by the user, or a random one can be generated. It is possible to specify the pattern to be used for random ID generation (see advanced manual). In case of manual prompt, the user may adopt the default namespace defined for the dataset and just create the localname, or can specify the entire URI by unsetting the lock icon on the right of the URI textfield
- skos:ConceptScheme icon on the top-right corner of the form: by default, all concept scheme are created by instantiating the skos:ConceptScheme class. However, it is possible for the user to specialize this class and create instances of the specialized class. If a subclass of skos:ConceptScheme is available, it is possible to select it by clicking on the related class icon, opening a tree selection form for picking up the desired specialized class.
Once one or more schemes are created, they will appear as a list in the structure section. Note that for each scheme is (independently) selectable, through the checkbox buttons on their left. The selection will affect the view on the Concept Section.
The Concept Section
The Concept Section is composed of two main areas as all other sections. The structure on the left, and the resource view on the right. The structure offers a tree-view very similar to the one in the class section, though here there is no Individual list (concepts are themselves instances of the class skos:Concept and have no instances on their own).
As we anticipated in the previous section, the tree view is affected by the selection of concept schemes performed on the Scheme section. Only those concepts belonging to at least one of the selected schemes will be shown on the tree. Note that:
- concepts are arranged in taxonomies, however the taxonomic relationships (skos:broader/narrower) between concepts are not scoped to the concept schemes, only the concepts are stated to explicitly belong to a scheme (skos:inScheme) or to be the top concept (skos:topConceptOf) of it. As a consequence, the each time a tree branch is explored by expanding a concept, the system first looks for all narrower concepts of the node that has been expanded, and then uses the selection of schemes from the Scheme section in order to filter out those not belonging to any of the selected schemes.
- being a top concept is not an intrinsic characterisc of a concept, but it is a binary relationship (c skos:topConceptOf s) involving a given concept c with a scheme s. The topConceptOf relation is mxn: each concept scheme contains more concepts and each concept can belong to more concept schemes. Note that there is not even an exclusivity concerning roots: though some KOSes may have "house-rules" preventing it, SKOS generally permits a same concept to have broader concepts in one scheme A and to be topConceptOf scheme B. Actually, A and B may even coincide, so that in a same scheme S a concept can be a root and still have broader concepts in S. It can thus happen to see a concept appearing twice (or more) in a forest determined by one or more schemes: as a root of a tree, and as a node in one other tree.
As evident from the figure above, the concept Car is both a top concept of the "main scheme", and a narrower concept of the concept Veichle, which is also present in "main scheme".
The Concept-view
The resource-view for concepts (or, simply, concept-view) is divided into a few sections listing the following information:
- Types: most of the concepts are of type owl:Concept. However, some concepts might have other custom classes as their definitory resources.
- Top Concept of: this section lists the schemes which the shown concept is a root concept of.
- Schemes: this section simply lists all the schemes which the shown concept belongs to.
- Broaders: this section lists all the broader concepts of the shown concept.
- Lexicalizations: the set of lexicalization of the concept for each language. The lexicalizations can be expressed through different models (rdfs:labels, skos or skosxl terminological labels) but are always presented here in a homogeneous way. Note: since SKOS-XL labels are reified, it is possible to click on them and open them on the resource-view. While this section hosts all kind of lexicalizations, it allows to create lexicalizations only according to the model specified when creating the project.
- Notes: skos:notes of various type (editorial notes, definitions etc..) can fit into this section. Note that notes can be refied according to the pattern specified in section 4.2 of the SKOS Primer. Whether notes are stored as simple rdf literals or resources, it depends on settings established at project creation. Notes are then created consistently along all the project and by all users.
- Properties: any triple not falling in any of the sections above, is reported in this section
The Collection Section
The Collection Section (as of all the data pages) is composed of two main areas: the structure on the left, and the resource view on the right. The structure offers as usual a tree, even though the semantics of the taxonomy here do not hint to some form of specialization, but to a containment relation. Collections may be normal collections (skos:Collection) or ordered collections (skos:OrderedCollection). Ordered collections, as their name suggest, represent ordered list of elements.
The Collection-view
The resource-view for collection (or, simply, collection-view) is divided into a few sections listing the following information:
- Types: most of the collection are of type owl:Collection or owl:OrderedCollection. However, some concepts might have other custom classes as their definitory resources.
- Lexicalizations: the set of lexicalization of the collection for each language. The lexicalizations can be expressed through different models (rdfs:labels, skos or skosxl terminological labels) but are always presented here in a homogeneous way. Note: since SKOS-XL labels are reified, it is possible to click on them and open them on the resource-view. While this section hosts all kind of lexicalizations, it allows to create lexicalizations only according to the model specified when creating the project.
- Notes: skos:notes of various type (editorial notes, definitions etc..) can fit into this section. Note that notes can be refied according to the pattern specified in section 4.2 of the SKOS Primer. Whether notes are stored as simple rdf literals or resources, it depends on settings established at project creation. Notes are then created consistently along all the project and by all users.
- Members: a collection is called as such because...it collects elements! These elements are listed under the Members section. The elements of a collection may be skos concepts or other collections. The tree on the left reflects the containment relation between collections.
- Properties: any triple not falling in any of the sections above, is reported in this section