XSLT for creating a subject index

Today I’ve been doing some documentation, storing up my archives of knowledge. I decided to write it up in the structured format of XML.

So that other people can understand the meaning of my XML, I selected elements from the dcterms namespace. That way, everyone can be sure we’re talking about the same thing when I call an element “subject”, or “title”.

Raw XML is not very pleasant for most people to look at, so I decided to attach an XSLT stylesheet to my XML so that when people click on the file it will open as a nice user-friendly html page in their browser.

Finally, I decided to tag each piece of documentation with some keywords. To make the document even more usable, I wanted to generate an index for these keywords at the end of the html representation of the page.

This proved to be a bit tricky, but with the help of this post by Mads Hansen on stackoverflow I got it done.

So, here is a stripped-back version of the XML, with only dct:title (for the title of each procedure document) and dct:subject (for keywords):

<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="blog.xsl"?>
<documents xmlns:dct="http://purl.org/dc/terms/">


<document id="001">
<dct:title>XML and information management</dct:title>
<dct:subject>XML</dct:subject>
<dct:subject>Information management</dct:subject>
</document>


<document id="002">
<dct:title>Information management and Controlled vocabularies</dct:title>
<dct:subject>Controlled vocabularies</dct:subject>
<dct:subject>Information management</dct:subject>
</document>


<document id="003">
<dct:title>Verbal aggression in the world of Controlled vocabularies: An action plan</dct:title>
<dct:subject>Aggression</dct:subject>
<dct:subject>Controlled vocabularies</dct:subject>
</document>
</documents>

You’ll notice that there are three documents, each with an ‘id attribute’, a title element in the dcterms namespace, and a bunch of subject elements in the dcterms namespace.

Here is what I want the index on the html page to look like:

Aggression

  • Verbal aggression in the world of Controlled vocabularies: An action plan

Controlled vocabularies

  • Information management and Controlled vocabularies
  • Verbal aggression in the world of Controlled vocabularies: An action plan

Information management

  • XML and information management
  • Information management and Controlled vocabularies

XML

  • XML and information management

Finally, here is the XSLT to do it (note that I have not included the parts of the XSLT to generate the actual contents, just the index):

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dct="http://purl.org/dc/terms/">
<xsl:output method="html"/>
<xsl:key name="documentBySubject" match="/documents/document" use="dct:subject"/>
<xsl:key name="subjects" match="/documents/document/dct:subject/text()" use="."/>

<xsl:template match="/">
<html>
<head>
</head>
<body>

<!--Generate contents here-->

<xsl:for-each select="/documents/document/dct:subject/text()[generate-id()
= generate-id(key('subjects',.)[1])]">
<xsl:sort select="."/>
<b><xsl:value-of select="."/></b>
<ul>
<xsl:for-each select="key('documentBySubject',.)">
<xsl:sort select="@id"/>
<li>
<xsl:value-of select="dct:title"/>
</li>
</xsl:for-each>
</ul>
</xsl:for-each>

</body>
</html>
</xsl:template>

</xsl:stylesheet>

Lets do a quick walkthrough.

The first couple of lines are administrative, specifying the ‘xslt’ and ‘dcterms’ namespaces.

Next we generate two sets of keys. The first set of keys (“documentBySubject”) is a list of documents identified by subject terms. The second set of keys (“subjects”) is a list of subjects.

The template begins at the XML document root. It starts off by creating some html. The next step would be to generate the body of the document, which I don’t do here in the interests of space.

The next section of code is crucial to our purposes – it generates the index. It commences by iterating over each subject term in the document. The xpath expression in the “select” attribute uses the “subjects” keys to group like-subjects, and to only select the first of each group. That is, we have created a node-list of unique subject terms.

The next line sorts these subject terms alphabetically.

Now, for each of our unique subject terms we create an unordered list. Then we select groups of documents using the “documentBySubject” keys, selecting groups on the basis of the current unique subject term we are iterating through. We sort these documents by the value of their ‘id’ attribute. For each document containing the given subject term, we print its title as a list item.

Finally, we close off our html and our xslt elements, and thats it.

Now, obviously we’d like to hyperlink our index, and we’d do that by making each list item a hyperlink, with the reference being to an internal anchor defined by the document’s ‘id’ attribute value.

And thats that.

Excel Tips: Conditional Statistical Functions

I haven’t been on here for ages, so I just thought I’d do a quick post about a handy Excel function trick that – it seems to me – not many people know about.

Lets say you have this data:

Lets say you want to summarize the Price data in Column B using one of Excel’s “Statistical” functions, except that you want to summarize on a per-Thing basis. That is, you only want Excel to perform the calculation for any given value in Column A, such as the total price of books, or the average price of Magazines.

To calculate the total prices or the average prices, Excel provides the SUMIF() and AVERAGEIF() functions, which look like this:

=SUMIF(A1:A11,"Book",B1:B11)

=AVERAGEIF(A1:A11,"Book",B1:B11)

However, if you want to find the maximum or minimum book prices, there is no equivalent MAXIF or MINIF functions. To calculate these conditional functions you have to do a bit of extra work. Here is what the formula looks like:

=MIN(IF(A1:A11="Book",B1:B11))

After typing the formula, hit Ctrl-Shift-Enter. This will insert curly brackets around the formula, thus:

{=MIN(IF(A1:A11="Book",B1:B11))}

The same trick works for any Statistical function, such as STDEV() or MEDIAN().

I recently used this to calculate the “most recent date” in a data-set. So if I wanted to know the last time a Book was sold, I could use the following:

{=MAX(IF(A1:A11="Book",C1:C11))}

Which would return “8-Jan-13”.

Quality control: Concepts with missing prefLabels in a specific language

We’ve recently added labels to about 900 high-level ScOT concepts in the four NALSSP priority Asian languages – Indonesian, Korean (which has recently been replaced by Hindi), Japanese, and Mandarin.

Unfortunately, some concepts were given a skos:altLabel or skos:hiddenLabel instead of a skos:prefLabel. I ran the following SPARQL query to find these concepts:

PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
SELECT ?uri
WHERE {
?uri a skos:Concept.
?uri ?b ?c.
FILTER (?b = skos:altLabel || ?b = skos:hiddenLabel)
FILTER (lang(?c) = “ja”)
OPTIONAL {?uri skos:prefLabel ?d.
FILTER (lang(?d) = “ja”)}
FILTER (!bound(?d))}
ORDER BY ?uri

Note the two locations where the language is specified: the lines “FILTER (lang(?c) = “ja”)” and FILTER (lang(?d) = “ja”) filter the the altLabel/hiddenLabel variables (?c) and the prefLabel variables (?d) to those that are in Japanese (“ja”). To screen a different language, replace “ja” with the relevant ISO3166 country code.

You can run this query here, but since we’ve fixed the problem it should return nothing. Let me know if it doesn’t!

 

 

SPARQL: Faceting search by working with narrower concepts

When a controlled vocabulary with heirarchical structure (such as a taxonomy or a thesaurus) is deployed in a searchable field in a search system, the system should make use of heirarchy to expand search results. So, if a user searches within that field for Concept X, the system should also return results tagged with the narrower concepts of Concept X. Optionally, it can also return results tagged with Concept X’s  grandchildren and/or subsequent narrower concepts all the way down the hierarchy tree (otherwise known as narrower transitive concepts, encoded as skos:narrowerTransitive).

This functionality can be implemented in many ways. When an RDF-based SKOS vocabulary is hosted online, a SPARQL end-point provides a way of delivering the vocabulary’s data dynamically. That is, the search system doesn’t need to store and work with a local copy of the data, and can be assured that the query results will always be up-to-date.

If a search system wants to store a local index of vocabulary concepts and their narrower concepts, which can be periodically updated from the vocabulary triple-store, it could use a query such as this one.

PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
SELECT ?label ?narrowerLabel
WHERE {
?uri a skos:Concept.
?uri skos:narrower ?narrower.
?narrower skos:prefLabel ?narrowerLabel.
?uri skos:prefLabel ?label.
FILTER (lang(?label) = “en”)
FILTER (lang(?narrowerLabel) = “en”)
}
ORDER BY ?label ?narrowerLabel

For all concepts that have narrower concepts, it returns the English-language preferred labels of the concept and English-language labels of its narrower concepts (so, concepts that have no narrower concepts will not appear in Column A of these results).

Also, note that this returns only the direct children (first-degree narrower-concepts) of concepts that have narrower concepts. As such, to identify narrower concepts across multiple hierarchy levels, the system will need to work across this data, drilling down from the query concept through its various narrower concepts.

An alternative way to go about it is to directly return the narrower transitives of a specific concept.

The following query used SPARQL 1.1 property-paths, allowing it to return the URI and prefLabel of not only the children, but all the narrower transitive concepts of the target concept (with preferred label “Health” in this case) .

PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
SELECT ?uri (str(?narrower) as ?label)
WHERE
{
?c a skos:Concept .
?c skos:prefLabel ?lab
FILTER (str($lab) = “Health”)
FILTER (lang(?lab) = “en”).
?c skos:narrower{0,2} ?uri .
?uri skos:prefLabel ?narrower.
FILTER (lang(?narrower) = “en”).
}

The levels of heirarchy returned, from the query concept downwards, are determined by the string “skos:narrower{0,2}” on Line 9. The “0” means ‘beginning with the target concept itself, and the “2” means ‘work down two levels of hierarchy from the target term’ (ie. grandchildren). These parameters can, of course, be modified, and follow regular-expression conventions. For example “skos:narrower+” returns narrower concepts through all levels of hierarchy but not the target itself, “skos:narrower*”  returns the target and all narrower concepts, and “skos:narrower?” returns the target and its children.

This ‘transitive functionality’ could be acheived in SPARQL 1.0, but the queries were terribly long, so I don’t care to include one here.

SPARQL for disambiguation

Words that look the same but whose meanings differ are called homographs. Homographs are an essential problem in information retrieval because a system is unable to determine the user’s intended meaning. When they ask for “Mouse” do they want to know about the animal or the computer accessory?

A core role of controlled vocabularies, such as synonym rings and thesauri, is to provide homograph control. This is achieved by maintaining unique preferred labels across all concepts. Ideally, this can be done without homographs, such as by using “Rodent” and “Mouse” to refer to the animal- and technological- “Mouse” concepts.

But sometimes there is no way around using homographs to refer to different concepts. In this case, the labels can be made unique via parenthetical qualifiers, such as Apple (Company) and Apple (Fruit).

In the latter case, if a user enters a search term that is a homograph, existing in two concepts, it is useful for the search system to identify this and act upon it, such as by seeking clarification from the user – “When you asked for ‘Apple’, I found two concepts. Do you want to know about the fruit or about the computer company?”.

RDF-based SKOS vocabularies that have a SPARQL endpoint permit systems to perform dynamic queries regarding semantic conflicts such as these. I developed the following SPARQL query to return the URI and English-language preferred label of all concepts whose English-language preferred labels or alternative labels contain the homographic termg and a parenthetical qualifier.

 

PREFIX skos:<http://www.w3.org/2004/02/skos/core#>

SELECT ?uri ?label

WHERE {

?uri a skos:Concept .

?uri ?lab ?label .

FILTER ( ?lab = skos:prefLabel || ?lab = skos:altLabel )

FILTER (lang(?label) = “en”)

FILTER regex( str(?label) ,

#REGULAR EXPRESSION

“(^Star)(es|s)?\\s\\u0028.*(\\u0029$)”, ‘i’ )

}

ORDER BY ?label

 

Relevant labels are identified by a regular expression ( immediately below the comment “#REGULAR EXPRESSION”). Concepts will be returned if their alt- or pref- labels meet these conditions:

  • (^Star) – The label begins with the homograph string (in this case “Star”)
  • (es|s)? – The search string may or may not be followed by pluralisation (“e” or “es”)
  • \\s – The search string (and any plurisation string, if present) will be followed at some point by a space
  • \\u0028 – At some point there will be a left parenthesis (the Unicode character for this is u0028)
  • .* – The left parenthesis will be followed by any number of characters
  • (\\u0029$) – The label will finish with a right parenthesis

If you run this query, you’ll find three concepts in ScOT that are homographs with parenthetical qualifiers.

SPARQL for Vocabulary Switching

Vocabulary switching involves matching the language used by users to the concept they are seeking. That is, if users search for a concept using a homograph (alternative label) of a concept’s preferred label, or a misspelling or lexical variation of a concept’s preferred labe l(hidden label), they will nonetheless be directed to the target concept.

Alternative labels (skos:altLabel) direct users to the concept from a homograph of the concept’s preferred label (skos:prefLabel), or a term deemed ‘close-enough’ within the scope of the vocabulary. “Therapists” might be an alternative label for a concept with the preferred label “Counsellors” (although this label should be disambiguated from the concept of governmental counsellors).

Hidden labels (skos:hiddenLabel) direct users to a concept from a common misspelling or other lexical variant of a preferred term. They are “hidden”, as opposed to “alternative” because although they are essential components of a search algorythm, they are not terms that are useful for display in a browse structure or A-Z list of terms. Hidden labels for “Counsellors” might be “Counselors” or “Counselling”.

For RDF-based SKOS vocabularies, systems need a way to access the data in order to allow vocabulary switching. A SPARQL endpoint provides this kind of API.

Here is a SPARQL query that returns the English-language preferred label of every concept in the vocabulary in (Column A), and the English-language hidden and/or alternative labels associated with that preferred label (in Column B).

PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
SELECT ?prefLabel ?otherLabel
WHERE
{
?s a skos:Concept.
?s skos:prefLabel ?prefLabel .
FILTER (lang(?prefLabel) = “en”)
?s ?label ?otherLabel .
FILTER (lang(?otherLabel) = “en”)
FILTER (?label = skos:hiddenLabel || ?label = skos:altLabel )
}
ORDER BY ?prefLabel

Alternatively, the following query returns the URI and English-language preferred label of a search term (which can be passed into the query as an argument). In this example, the search term is “Chance”, which is a ScOT alternative label for “Probability”.

PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
SELECT ?URI ?term
WHERE {
?URI a skos:Concept.
?URI ?p ?label.
?URI skos:prefLabel ?term
FILTER (lang(?term) = “en”)
FILTER (str(?label) = “Chance”).
FILTER (lang(?label) = “en”).
FILTER (?p = skos:prefLabel || ?p = skos:hiddenLabel || ?p = skos:altLabel).
}

A SPARQLing new autocomplete algorithm

Users of the ScOT vocabulary are able to find concepts either by browsing through the hierarchy, or by searching for concepts from a search field on the vocabulary pages’ upper-right corner.

Typing in the search field produces a drop-down-style list of suggested concepts, so user’s search is directed to exact matching terms. User’s input in the search field is auto-completed, based on a search of preferred , alternative, and hidden labels of concepts in the ScOT triple-store.

This dynamic updating of user’s input is achieved by AJAX, which sends XMLHttpRequests from the browser to the server and updates a section of the page (namely, the drop-down list) based on the server’s response, without having to refresh the whole page each time.

By default, the PoolParty software uses Apache’s Lucene information retrieval software library as the algorithm for querying the ScOT data and returning results based on user’s input in the search field (that is, the search is “powered by” Lucene). However, a recent release of PoolParty allows customization of the search algorithm by specifying custom SPARQL queries. That is, the search can be “powered by” ScOT’s own SPARQL end-point.

I’ve been working on developing a SPARQL query that will meet our specific preferences in relation to autocompletion of user’s search input. These are the parameters I am working from:

1)      The search text should be sought amongst the preferred-language skos:prefLabel, skos:altLabel, and skos:hiddenLabel elements of the ScOT data

2)      The relevance of all matching concepts should be determined by:

  1. Left-stemming: The distance of the search text from the left-hand side of the label in which the search text is found. That is, labels beginning with the search text are given preference over labels in which the search text is found somewhere within the label. Thus, the label “Achievement” will be rated more highly than “Machinery” for the search text “ach”
  2.  Proportional match: Within labels with equal value on the left-stemming rule, preference should be given to shorter labels. This not only produces a pleasant, tree-like visual effect, but gives preference to labels with a tighter lexical match to the search text. That is, the search text makes up a greater proportion of the total length of the label. For the search text “ach”, the label “Achievement” will be rated more highly than “Achievement testing”

3)      The URI and skos:prefLabel of the top 20 matches should be returned

I developed the following SPARQL query to meet these criteria (the search text “ach” is used in this example):

PREFIX :<http://www.w3.org/2004/02/skos/core#>

SELECT DISTINCT  ?uri ?label

WHERE  {?uri a :Concept.

?uri  :prefLabel ?label.

FILTER (lang(?label) = “en”).

?uri  ?b ?lab.

FILTER (?b= :prefLabel || ?b=:altLabel || ?b= :hiddenLabel)

FILTER regex (str($lab), “ach”, ‘i’)

FILTER (lang (?lab) = “en”).

BIND (STRLEN(STRBEFORE (str(?lab), “ach”)) AS ?place).

BIND (STRLEN(STR(?lab)) AS ?len)}

ORDER BY ?place ?len ?lab

LIMIT 20

Let’s do a walkthrough of this query:

  • Line 1: Specifies that the SKOS namespace is the default namespace for this query
  • Line 2: The data to be returned is the concept’s URI (as defined on Line 3) and skos:prefLabel (as defined on Line 4)
  • Line 3: Selects all elements defined as a skos:Concept
  • Line 4: Include the skos:prefLabel of those concepts in the query
  • Line 5: Filter out any results with a skos:prefLabel that is not in English
  • Line 6 and 7: Includes in the query all labels associated with the concept, whether they are skos:prefLabels, skos:altLabels, or skos:hiddenLabels
  • Line 8 and 9: Filter out of the query any results whose labels (from Line 6 and 7) do not contain the search text (which is case-insensitive) or are not in English
  • Line 10: Create a new variable representing the number of characters in the label that occur to the left of the search text (this is for evaluating left-stemming)
  • Line 11: Create a new variable representing the length of the label (this is for evaluating the proportional match)
  • Line 12: Order the remaining results in order of: the variable defined in Line 10 (left-stemming), the variable defined in Line 11 (proportional match), and the label itself (alphabetical ordering of the matching label)
  • Line 13: Of these results, return only the first 20 (these will be the top-matching concepts because of the ordering performed in Line 12)

So all the matching and ordering of results is done against a label – which may or may not be the preferred label – but the final result set consists of the URI and the preferred label.

I’ve encoded the query into this URL, so you can perform it dynamically and check out the results yourself.

Remember that this query is not ScOT specific — it will provide the same functionality on any SKOS-based vocabulary.

Out of interest, before SPARQL 1.1 came along, my draft autocomplete query was very different. Keywords such as BIND, STRLEN, STRBEFORE and AS were not available, so none for the ranking and ordering capabilities could be performed within SPARQL. Here is my much-more-basic SPARQL 1.0 autocomplete query:

PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
SELECT ?prefLabel ?URI
WHERE
{
?URI a skos:Concept.
?URI ?p ?label.
?URI skos:prefLabel ?prefLabel.
FILTER regex(str(?label), ‘dire’, ‘i’).
FILTER (?p = skos:prefLabel || ?p = skos:hiddenLabel || ?p = skos:altLabel).
FILTER (lang(?label) = “en”).
FILTER (lang(?prefLabel) = “en”).
}
ORDER BY ?label

All it does is returns the URI and English-language preferred label of all concepts whose English-language prefLabel, altLabel or hiddenLabel contain the search string. Results are orders alphabetically according to the matching label, but all ranking and limiting of results is left to the downstream system.

Committing to SPARQL notions

Human users of the ScOT thesaurus can search and browse via the comfort of our web-based user interface. However, as a machine-readable vocabulary – encoded in RDF and stored on a Sesame triplestore database – we want it to be just as easily accessed and used by automated systems anywhere.

There are many ways of providing this kind of access, which we can call an Application Programming Interface (API). One method provided out-of-the-box by the PoolParty software is called a SPARQL end-point.

Just as SQL is a language that allows you to query a relational database, so SPARQL is a language that allows you to query a triple-store. SPARQL is SQL with a twist – if you are familiar with SQL it shouldn’t take too long to get your head around SPARQL.

In order to query an RDF data-set using SPARQL, a SPARQL end-point must be available for the triple-store. The ScOT SPARQL end-point is at http://vocabulary.curriculum.edu.au/PoolParty/sparql/scot. We have recently upgraded from SPARQL 1.0 to SPARQL 1.1.

Look at this simple SPARQL query (which is an example from the PoolParty SPARQL end-point):

PREFIX skos:<http://www.w3.org/2004/02/skos/core#>

SELECT DISTINCT ?Concept ?prefLabel

WHERE { ?Concept a skos:Concept .

{ ?Concept skos:prefLabel ?prefLabel .

FILTER (regex(str(?prefLabel), ‘^a.*’, ‘i’)) } }

ORDER BY ?prefLabel

This query returns the URIs and preferred labels of all concepts that start with the letter “a”, sorted alphabetically by label. Specifically it specifies:

  • Line 1: the SKOS namespace, for use in the query
  • Line 2: that the results should display all unique (DISTINCT) combinations of concept URIs and their preferred labels
  • Line 4: that all RDF entities defined as a skos:Concept should be queried
  • Line 5: that all skos:Concepts that have a skos:prefLabel should be retrieved
  • Line 6: that all concepts except those with a skos:prefLabel beginning with ‘a’ should be filtered out (this is a ‘regex’ regular expression statement)
  • Line 7: that results should be ordered by skos:prefLabel. That is, alphabetically.

You can cut-and-paste that query into the ScOT SPARQL endpoint and see a nice table of results. Or, by encoding the query to be URL-friendly (by using a tool such as this), you can include it as an argument at the end of the URL for the SPARQL-endpoint. You can then run the whole query through the URL, which is what a remote machine might do. The results will be returned in machine-readable XML.

I have already developed a few applications that utilize the ScOT SPARQL end-point, some of which I will go into in future posts. Briefly though:

  • An indexing tool, referred to as the ScOT Hierarchical Relationship Locator (SHiRL), that identifies any hierarchical relationships between a set of query terms. A tool such as this is useful because it helps cataloguers to avoid tagging a resource with two terms that are hierarchically redundant, because one is, say, a child or grand-child of the other.
  • A tool that allows ScOT users to examine new, modified, or deprecated concepts over a period of time.
  • I have developed a range of reports, for use in our annual reports amongst other things, based on queries to the SPARQL end-point and formatted using velocity templates. For example, one report identifies concepts with 15 or more narrower terms. Another report counts the number of concepts at each hierarchical level. Another identifies any non-unique preferred-, hidden-, or alternative- labels between or within concepts. A further report exports the entire thesaurus into standard paper-based thesaurus format.

The beauty of the kinds of SPARQL queries I have been developing is, because ScOT is built upon the SKOS standard, they can be used to query any SKOS-based dataset. Tools developed for ScOT can be used just as easily on other SKOS-based vocabularies just by changing the SPARQL endpoint.

I have also recently begun querying the RDF for the Australian Curriculum (AC) by downloading the AC RDF to my local drive and importing it into the Sesame 2 Windows Client, allowing me to do some fancy things running queries between the AC and ScOT. But that is a story for another day.

In future posts I will outline a few ‘choice’ SPARQL queries for use in SKOS vocabularies.

Release of ScOT Version 6.7

Within the last week, the Schools Online Thesaurus has released Version 6.7. You can check out the details via these blog-posts from the Schools Catalogue Information Service (SCIS) or from the Semantic Web Company (the publishers of the Poolparty software we use to manage the thesaurus).

I’m happy to say that I played a significant part in this release, including:

  • Performing many of the updates to the ScOT website to ensure WCAG 2.0 AA (accessibility) compliance
  • Programming an email form for user feedback
  • Programming a cataloguing tool that allows cataloguers to check the hierarchical relationship amongst terms
  • Programming a form allowing users to check for new, modified, or deprecated terms within a given date range
  • Devising a set of SPARQL queries for use by developers
  • Coordinating the publication of 48 new concepts, 7 modified concepts, and 97 new hidden- and alternative-labels

The ScOT website is currently in old-style ASP, so most of the work above was done in HTML, CSS, Javascript, and vbscript, with a bit of SPARQL syntax thrown in to perform dynamic queries of the ScOT triple-store, via the Poolparty SPARQL end-point.

If I get around to it, I’ll post again soon to provide a bit more detail on some of these features, and their back-end details.

Cheerio,

Ben

 

bcTerms:firstPost

Welcome to bcTerms!

I’m Ben Chadwick, and this is my blog. You can read more about me on linkedin, or at bchadwick.com. Briefly, I currently work for Education Services Australia, in Melbourne, helping to maintain the Schools Online Thesaurus (ScOT). I recently graduated from a Graduate Diploma Information Management at RMIT, and am currently completing a Graduate Diploma in Internet and Web Computing at RMIT. My background is in Psychology, both as a clinician and an academic, having completed my PhD at the University of Queensland in 2006.

The title of the blog is a reference to the metadata element set, ‘dcTerms‘, which specify a set of fields – or ‘elements’ – used to describe a resource (usually electronic, such as a website), and the meaning (‘semantics’) of that element.  I cleverly replaced ‘dc’ (which refers to ‘Dublin Core’) with ‘bc’ (which refers to ‘Ben Chadwick’). So now you know.

I’ll post stuff on here whenever the universe allows me the time and head-space to create content that meets minimal standards of readability, creativity, interest and/or utility. It may not happen that often. The types of content relevant to this blog may include:

– Metadata standards, including Dublin Core and those relating to educational resources (eg LOM) and academic research (eg DDI)

– Controlled vocabularies (including thesauri and taxonomies), ontologies, and folksonomies

– The semantic web, including standards such as RDF, OWL, SKOS, and SPARQL

– Web programming and data-related aspects of the above topics, including HTML, CSS and Javascript, XML, and languages such as PHP, ASP and ASP.NET,  and Java

I won’t kid you – I’m still getting my head around this stuff , so this blog will really be a documenting of my own learning adventure.

 

Now for a quiz to see whether you’re still with me:

A) What metadata standard does the title of this blog reference?

  1. a – dcComics
  2. b – dcTerms
  3. c – Bokonon
  4. d – All of the above

 

B) Where did I complete my Information Management studies?

  1. a – R.M.I.T.
  2. b – R.E.S.P.E.C.T.
  3. c – University of Queensland
  4. d – Miskatonic University

 

C) What server-side scripting language may be discussed in this blog?

  1. a – PDP
  2. b – PCP
  3. c – PHP
  4. d – Both (a) and (b)

 

I hope you’re still with me, and that you got full marks for the quiz. (By the way, the correct answers were A3, B4, and C4).

Maybe I’ll see you around these parts again some day soon.

Warmest regards,

Ben