Representing defining and using ability competency and similar concepts
Here are notes on each of the technical components of the suggested architecture. I hope these help towards thinking about implementation of systems dealing with information about abilities. (As elsewhere, the term "ability" used here is intended to cover other terms including skill, competence, competency.)
In this page, first the simple matter of URIs is clarified, then the key Semantic Web concepts. SKOS gives a model for the required content for defining relations between ability concepts, while the later sections give examples and suggestions of how suitable RDF - triples with those SKOS predicates - could be embedded in other formats.
Most people understand the basic notion of using URIs (uniform resource identifiers), extending to internationalized IRIs. There is in principle a distinction between URIs, as the identifiers of the ability concepts (under whatever name), and URLs, as the locators of web pages giving information about them.
The proposal here is to follow the discussion in the W3C's "Cool URIs" note. The URIs to be used are of the same form as URLs, using http at the beginning. While ordinary URLs can be used to identify concepts, as well as pages of information about them, this can cause confusion within the Semantic Web, and "Cool URIs" suggests using either of two approaches for distinguishing the two. The first approach is for the identifier of the ability concept to ends with a "#" part, which is commonly used on the web to point to an anchor within a web document, but need not do so. In any case, such a URI cannot by nature refer directly to a web document, or "information resource", as a whole, so is safe to use to identify a concept rather than an information resource. The second approach is for the URI to be redirected (with code 303) to the location of the information about it. See the Cool URIs note for further details.
The W3C has many pages of information on its Data Activity, including the old Semantic Web materials; and the Resource Description Framework, RDF.
The key idea in the RDF is that information is able to be represented, equivalently, as either a directed graph, or a set of triples of the form [subject, predicate, object]. This is a highly general way of representing "knowledge", and just as applicable to the area of abilities as it is to any other area. There are other general purpose representations, notably Topic Maps, which could be used, but are not the focus of these proposals.
SKOS, the W3C's Simple Knowledge Organization System, currently (July 2009) is a proposed "Recommendation". It gives properties (or "predicates", in RDF terminology) useful for describing relationships between concepts in general, including the kinds of relationships commonly found in the likes of "thesauri, classification schemes, subject heading systems and taxonomies".
The most significant part of the SKOS relationships pointed out in the basic how-to page are the mapping properties. But the mapping properties are sub-properties of the basic SKOS properties, so we will start by looking at these more general semantic relations, and intepreting these in terms of ability concepts.
The SKOS mapping properties are "used to state mapping (alignment) links between SKOS concepts in different concept schemes". While the plain semantic relations do the general job of relating terms within a framework of abilities, the mapping properties are potentially well-adapted for relating ability concepts as defined by one body to comparable ability concepts as defined by another body. There are four of particular interest: closeMatch, exactMatch, broadMatch and narrowMatch. There is a useful section in the SKOS primer describing the application of these properties.
This are sub-properties respectively of skos:broader and skos:narrower. As suggested above for the semantic relations, one interpretation of skos:broadMatch for abilities would be "may help towards" or "may contribute to"; a similar interpretation of skos:narrowMatch might be "satisfies".
It is very useful that SKOS has these two distinct relational properties. When constructing a framework of ability definitions, there are two possibilities for each ability concept to relate closely to another very similar concept. The first possibility is that an external definition can simply be adopted as it is. In other words, the effort is put entirely into choosing a fully adequate external definition, and then accepting all of its properties, including any other ability concepts that have been defined as exactly the same as that. This corresponds to skos:exactMatch. The second possibility is that you want to say that you accept the other definition as equivalent for practical purposes, in that you will accept a claim to that ability as equivalent to a claim to the ability as defined by you. But the definitions may not use exactly the same words. Furthermore, you don't want to commit yourself to accepting what they might say is practically equivalent, as practical for you might differ from practical for them. This is skos:closeMatch.
SKOS define exactMatch as transitive, but that cannot be said of closeMatch. This is probably what is wanted in the two cases just described.
If there is no additional structure, such as RDFa or microformats, allowing the extraction of RDF from the body of an HTML document, suitable SKOS RDF can still be added to the head of an HTML document through link and meta elements.
One way of doing this for Dublin Core information is described in this Dublin Core document.
The RDFa primer describes how to embed RDF in HTML in a way that is straightforward to extract, and maximises the reuse of the same information for human reading and potential machine processing. One particular worked example is given in the related work.
Next: practicalities.
| index | web | publications | Simon Grant | © 2009 07 |