Author

Representing defining and using ability competency and similar concepts

Technicalities

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.

URIs

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.

Semantic Web and RDF

The W3C has many pages of information on the Semantic Web and its Resource Description Framework, RDF. Helpful introductory material not from the W3C includes

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

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.

SKOS semantic relations and abilities

NOTE: I have changed this section – 2009-07 – the interpretation of broader and narrower are reversed.

skos:broader
The term itself sounds ambiguous. The intention in fact is that "A skos:broader B" means that B is a broader term than A, in the normal classification sense of "broader term". That is, the concept B covers all the things covered by A and more. (See the discussion in Section 2.3.1 of the primer, where "broader" is stated to be understood as "has broader concept".)
Unfortunately, there are two opposite ways in which this can be applied in terms of ability. An ability which covers more things that someone is able to do covers fewer people. If we think of this example: The ability B has a broader coverage than the ability A, but in terms of people with that ability, clearly there are more people with ability A than ability B. Staying with judging on the extent of the ability, not the number of people covered, B is a broader concept than A, so in terms of SKOS, we would write "A skos:broader B" meaning A has a broader concept than it, which is B. Thus, one could say that "A skos:broader B" could be read as "A contributes to B".
skos:narrower
This is exactly the inverse of skos:broader. One way of stating this relevant to ability requirements is in terms of satisfaction. The (more demanding) ability to race Formula 1 cars (B) satisfies the requirement for the ability to drive a car (A). Another way of stating this might, for example, be "B satisfies A".
skos:related
This property is not obviously so useful in defining and representing abilities, because is could be used very widely. SKOS defines the property as symmetric: that is, if A skos:related B, it follows that B skos:related A. This rules out concepts which are related by skos:broader and skos:narrower.
skos:broaderTransitive
skos:narrowerTransitive
These are technical variants of broader and narrower, and need not concern us directly.

SKOS mapping properties

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.

skos:broadMatch and skos:narrowMatch

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".

skos:exactMatch and skos:closeMatch

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.

Ways of representing RDF other than plain RDF

XML and GRDDL

If the needed SKOS RDF is to be extracted from an XML file, there needs to be a transform(ation) associated with that XML schema.

GRDDL is another W3C recommendation for "Gleaning Resource Descriptions from Dialects of Languages". As the name implies, it is a method of defining transform(ation)s associated with specific XML dialects to extract information in RDF form.

Here is a useful presentation, which also goes into RDFa and microformats. However, the link to micromodels.org is out of date. Instead, a useful general reference is

Extra information within the head of HTML documents

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.

XHTML and RDFa

RDFa is a W3C recommendation (2008-10-14). The RDFa primer describes how to embed RDF in XHTML 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.