Following our analysis of SKOS vocabularies publicly available on the Web, we found several types of `irregularity' in some of the vocabularies' representation [1]. We have considered these `defects' as slips made by vocabulary engineers when authoring the vocabularies. In many cases these slips are apparently due to either syntactic error or accidental misuse of the SKOS core vocabulary. In this paper, we present a typology of these slips, and describe possible patches that can be applied to deal with the problems. By `patching' these slips, vocabularies can be adjusted to conform to the SKOS standard and thus enable the usage of SKOS tools/applications.
The results from our previous survey of SKOS on the Web [
Apparatus All experiments were performed on a 2.4GHz Intel Core 2 Duo
MacBook running Mac OS X 10.6.8 with a maximum of 3 GB of memory allocated
to the Java virtual machine. Two reasoners were used: JFact3, which is a Java
version of the FaCT++ [
Preparing a corpus of candidate SKOS vocabularies As described in [
Validating SKOS vocabularies All candidate SKOS vocabularies gathered
in the previous step were tested for SKOS `validity'. We proposed in [
Each candidate SKOS vocabulary was screened in the following way to identify it as a SKOS vocabulary: 1. Check for the existence of direct instances of type skos:Concept; if Yes, then accept the vocabulary as a SKOS vocabulary. 2. Check for the existence of implied instances of skos:Concept due to domain and range restrictions on SKOS relationships (for example the subject of a skos:broader, skos:narrower or skos:related relationship is necessarily a skos:Concept); if Yes, then accept the vocabulary as a SKOS vocabulary.
html
3. Otherwise, do not accept this vocabulary as a SKOS vocabulary.
Consider the following vocabulary snippets written in Manchester Syntax7. Vocabulary 1 and Vocabulary 2 are accepted as SKOS vocabularies based on tests in Step 1 and Step 2, respectively. Meanwhile, Vocabulary 3 is not accepted as a SKOS vocabulary according to our de nition, even though this vocabulary uses SKOS constructs such as skos:prefLabel and skos:altLabel. If Vocabulary 3 was to be included as a SKOS vocabulary, one could expect any ontology that uses SKOS annotation properties for labelling their entities to be included in the survey.
Detecting and classifying slips In the SKOS vocabulary validation stage, we recorded the list of URLs of candidate SKOS vocabularies that do not pass the `SKOS validity test'. These URLs are then screened for SKOS constructs used in the vocabularies using the OWLAPI. In this screening stage, we are looking for candidate SKOS vocabularies that use to following SKOS constructs, but were failed to be detected in the previous stage.
{ skos:broader { skos:narrower { skos:related { skos:Concept { skos:hasTopConcept { skos:topConceptOf Utilising the functionality provided by the OWL API, we then checked the entity types of the listed SKOS constructs recognised by the OWL API and recorded them for each candidate SKOS vocabulary.
We also kept a list of the URLs of candidate SKOS vocabularies that were inconsistent when we classify with an automatic reasoner such as JFact or Pellet. For each of the candidate SKOS vocabularies that failed to be classi ed, we recorded the exception message thrown by the reasoner together with the cause of the inconsistency.
Each impaired SKOS vocabularies was manually inspected for any sign of deviation from SKOS that would account for the irregularity. We classi ed these irregularities into several types.
Out of 6819 URLs in the corpus, 5751 URLs failed to be validated as a SKOS
vocabulary [
There were 47 URLs identi ed in the slips detection stage, with 18 documents detected using the listed SKOS constructs, and the rest were `inconsistent' ontologies. Table 1 shows a summary of the results.
The information regarding the entity types returned by the OWLAPI, revealed
that all SKOS properties such as skos:broader, skos:narrower, etc. are of
type owl:AnnotationProperty. Further inspection of the source of the
vocabulary showed that each SKOS property used in the vocabulary was not
explicitly typed as any of the possible property types such as owl:ObjectProperty,
8 http://www.w3.org/2004/02/skos/core.rdf
owl:DataProperty or owl:AnnotationProperty. Note that the SKOS
specication [
AnnotationProperty(http://www.w3.org/2004/02/skos/core#broader) AnnotationProperty(http://www.w3.org/2004/02/skos/core#narrower)
This type of slip was identi ed through the exception thrown by the reasoner
when it failed to classify the vocabularies. We found 6 candidate SKOS
vocabularies that were inconsistent, caused by a `mis-use' of SKOS constructs. From our
inspection of the SKOS constructs usage in the vocabularies, we can categorised
this type of slip into 2 categories.
(a) Mistyping of an individual to be an instance of both skos:Concept
Scheme and skos:Concept. The SKOS Reference [
Concept Individual: urn:cgi:classifier:CGI:StratigraphicRank:200811:lithodeme Types:
Concept Facts: inScheme urn:cgi:classifierScheme:CGI:StratigraphicRank:200811, prefLabel "Lithodeme"@en disjoint classes in the SKOS data model. Therefore, since the rdfs:domain of the skos:narrower property is skos:Concept, using a skos:narrower to relate a concept to a collection will violate this constraint, causing the vocabulary to be inconsistent. In the SKOS data model, the correct property to use to relate a member to a collection is skos:member. Further inspection of the vocabulary also showed that the skos:member property was declared but never used. Figure 3 shows a snippet of a vocabulary with this type of slip. 1 candidate SKOS vocabulary was classi ed to have this type of slip.
Class: Collection
Individuals:
_:genid1 Individual: milk
Types:
Concept Facts: narrower genid1, prefLabel "milk"@
Type 3: Use of an invalid or use-de ned datatype.
This type of slip was also identi ed based on an exception thrown by the reasoner when it failed to classify the vocabularies. This type of slip was due to a userde ned or invalid datatype not being recognised by a reasoner. Besides, the use of user-de ned datatypes is not a problem from the SKOS point of view, instead it is a problem in the context of OWL 2 DL. We found 23 candidate SKOS vocabularies having this type of slip, 9 vocabularies due to user-de ned datatypes and 14 vocabularies due to invalid datatypes. 4
As reported in the previous section, some of the slips are merely syntactic errors which could be xed by 'simple' patching to the syntax, while others may require some judgement in order to avoid altering the intended meaning of the SKOS vocabulary. In this section, we introduce approaches to x these slips. 4.1
Type 1: Undeclared property type.
There are two possible patches to x the slip described in Section 3. 1. Patch 1: Addition of missing declarations.
Search for all SKOS-related constructs in the vocabulary and add the missing declarations for these constructs. For example, if the properties skos:broader, and skos:narrower were found in the vocabulary, we would add declarations for both of these properties to be of type owl:ObjectProperty. 2. Patch 2: Import the SKOS core vocabulary.
Another possible approach to x this problem is by importing the SKOS core vocabulary9.
Applying either patch xed the problem. We applied the Patch 1 xing procedure and xed 18 SKOS vocabularies of this category. 4.2
Type 2: Mis-use of SKOS constructs.
Mistyping of an individual to be instances of both skos:ConceptScheme and skos:Concept classes.
To ` x' this type of slip, we propose the following procedures: 1. Search the vocabulary for the mentioned individual X. 2. Check the existence of axiom(s) relating other SKOS concept(s) to individual
If Yes, this indicates that individual X, is inferred to be of type skos:ConceptScheme. 3. Check if the existing declaration for individual X as type skos:Concept. If
Yes, then remove this declaration from the vocabulary.
Applying these ` xing' procedures xed the ve SKOS vocabularies in this category.
Incorrect use of skos:narrower property to relate a concept to a collection. 1. Search the vocabulary for the mentioned individual X. 2. Check if the existing declaration for individual X as type skos:Collection. 3. Check for the existence of axiom(s) relating other SKOS concept(s) to individual X through skos:narrower property. For example, <Y> skos:narrower <X>. If Yes, this indicates that individual X, is inferred to be of type skos:Concept.
Applying these ` xing' procedures xed the one SKOS vocabulary in this category. 4.3
Type 3: Use of an invalid or user-de ned datatype.
The patch this type of slip, we do the following. For the user-de ned datatype problem, we rst checked whether the user-de ned datatype was actually in use to type the data in the vocabulary. If the datatype was not in use, we excluded the datatype from the datatype list and reclassi ed the vocabulary. For the invalid datatypes problem, further judgement was needed in xing this problem. We xed 0 vocabularies for this type of slip.
The number of SKOS vocabularies for each type of slips and the results of patching are summarised in Table 2 We conjecture that some of these slips are merely due to authoring tools used by the ontology engineer to author the vocabulary, while some others are due to mistakes in authoring the vocabulary.
The `patching' procedures proposed in Section 4 could be done manually or implemented through an automated `patching' process. Having an automated `patching' process would make the vocabulary `repairing' more scalable than the manual approach we used. These procedures could also be incorporated into SKOS parsers or validator tools to help avoid errors at source.
E orts in detecting and patching errors in Semantic Web documents were described in [9, 10]. However, these works focused on OWL ontologies rather than KOS style artefacts. The PoolParty Consistency Checks for SKOS Thesauri10 provides an on-line service for checking integrity and consistency of a given SKOS thesaurus. At the end of the checking process, the check result will be displayed, including error(s), if any. So the survey and repairs we report here lls a potentially useful gap for authors of semantic artefacts. 5.1
Recommendations for SKOS Vocabulary Best Practices
We reported in [
VE: Declare all concepts used in the vocabulary as type skos:Concept. This is because some SKOS tools like SKOS Reader rely heavily on this declarations as the rst step in identifying instances in the vocabulary. Without this declaration, this kind of tool is not able to display the vocabulary correctly. AD: If no SKOS concept were found, look for use of SKOS semantic relations that can infer the use of SKOS concept through the domain and range constraints.
VE: Whenever an assertion is made between two concepts using either the skos:broader or skos:narrower property, always add the inverse relation for this assertion.
AD: When found only one assertion of skos:broader or skos:narrower property between two SKOS concepts, always infer the inverse relation for this assertion. 3. Import SKOS core vocabulary.
VE: The best way to avoid slip Type 1 is to import the SKOS core vocabulary11. I doing so, the problem of missing type will be solved.
AD: Similarly, an application designer could import SKOS core vocabulary when loading the vocabulary and use the reasoner to classify the vocabulary.
For Best Practices 1 and 2, the application designers could also consider
applying a reasoner to classify the vocabularies to be used with their tools [11].
For Best Practice 1, if the vocabularies do not typed their SKOS concepts,
but instead used SKOS semantic relations like skos:broader, the knowledge
about this skos:Concept could be inferred from domain and range constraints
10 http://demo.semantic-web.at:8080/SkosServices/check
11 http://www.w3.org/2004/02/skos/core.rdf
of these relations. Similarly, as shown in our previous survey [
We have presented a typology of slips in SKOS vocabularies on the Web. We
found that some of these slips are syntactic errors, while others appear to be
mistakes in understanding the use of SKOS constructs by vocabulary engineers.
We admit that the types of slips presented in this paper are based on a rather
small collection of SKOS vocabularies in our corpus. We showed that some of
these slips can be corrected by applying `simple' patching procedures, while
others require some judgement and further knowledge of the intentions of the
vocabulary engineers. We also discussed other issues from the survey in [
Uretsky, M., Najork, M., Wills, C.E., eds.: WWW, ACM (2004) 266275 10. Bechhofer, S., Volz, R.: Patching syntax in OWL ontologies. In: Proceedings of the 3rd International International Semantic Web Conference. (2004) 11. Solomou, G.D., Koutsomitropoulos, D.A.: Support of SKOS vocabularies in the DSpace digital repository system. In DSpace Federation 5th User Group Meeting (Poster) (2009)