Its been a long time…

The original SENESCHAL project to create the heritagedata.org site, data, services and widgets ended way back in early 2014. In the intervening 5 years the resources have been utilized in a number of useful scenarios, and heritagedata URIs have found their way into many systems as points of reference. The vocabulary data itself has been maintained, extended and improved by members of the respective originating heritage organizations. However during this time the underlying platform actually remained fairly static. We are now performing some long overdue maintenance tasks on this platform, upgrading the underlying software and introducing an SSL certificate for https URIs (although persistent concept and scheme URIs will remain the same). We are also taking this opportunity to make some requested improvements to the web services, for example including scope notes with concepts in the returned data. There may be some slight changes required to the widget code to enable the widgets to continue functioning correctly. There will inevitably be a small amount of disruption to services during this time but we hope to keep this to a minimum.

SENESCHAL project case study features in the Scottish Government Open Data resource pack

The Scottish Government have just published an Open Data Resource Pack, developed to support Scotland’s Open Data Strategy which was published in February 2015. The Strategy sets out the Scottish Government’s ambition for making data open and available for others to use and reuse. The release of data in this way will provide a societal asset which offers significant benefits to many.

The Open Data Resource Pack has been developed with support and input from organisations throughout the Scottish public sector. It provides handy tips and guidance to help public authorities throughout Scotland develop their own plans for open data. Open data is non-personal and non-commercial data which is made available online in machine readable formats and can be used, and reused for any purpose as it is available under open license. This guidance covers all the steps organisations should consider when they are thinking about releasing their data openly

The resource Pack features a case study on SENESCHAL as a successful project in publishing Linked Open Data.

 

Peter McKeague

Gaelic thesaurus: Historic Scotland Press release

To launch their Gaelic thesaurus, Historic Scotland have issued a press release.  The article includes references to http://www.heritagedata.org/ as the home of Linked Data vocabularies for cultural heritage data and the SENESCHAL project, led by the Hypermedia Research Unit at the University of South Wales.

So far the story has been picked up by The Herald and The Oban Times.

SENESCHAL on the road

Towards the end of the SENESCHAL project a series of workshops were organised to engage with interested parties and project partners, to demonstrate the various outcomes of the project and to discuss possible future directions. The first of these workshop was held at the offices of Historic Scotland in Edinburgh on Thursday 13th February 2014. Despite severe winds and flooding significantly affecting travel plans the workshop went ahead and was attended by an engaged and enthusiastic group originating from a variety of organisations. From our point of view the Q&A was particularly fruitful, providing good insight into areas where people thought the Linked Data and web services approach might be particularly helpful.

The second of the three workshops was held at the Archaeology Data Service, King’s Manor, York on Thursday 20th February 2014. Once again an interested and engaged audience attended and there were stimulating discussions on all aspects of terminology usage. One significant topic of discussion concerned the use of HeritageData resources in applying validation and quality control to archaeological datasets to improve vocabulary usage.

The final workshop took place at the offices of the Royal Commission on the Ancient and Historical Monuments of Wales (RCAHMW) in Aberystwyth on Thursday 27th February 2014. We observed examples of terminology usage within a number of online applications where SENESCHAL outcomes could potentially have a supporting role. The group were also understandably interested in future possibilities regarding multilingual vocabulary resources, following a demonstration illustrating how Scottish Gaelic terms had been incorporated into the RCAHMS Monument Types thesaurus.

Themes emerging from all workshop discussions included:
The need for more information on update procedures – how to keep the online Linked Data current
Connected with this, discussions on how versioning and version control techniques may apply
Useful ideas were expressed on possible additions to the web services and widgets initially made available

The presentation slides used in the workshops are available here (PDF, 3MB)

Vocabularies in a useful form

Repeated references to RDF, SKOS, LOD, and REST services can sometimes seem an impenetrable wall of jargon leaving some people cold – how do we actually use all this stuff? Well the good news is that 99% of what you need is already implemented here at HeritageData. To use any of the controlled vocabularies in your own web pages or applications you can employ the brand new SENESCHAL widgets. This is a suite of predefined visual user interface controls that dynamically obtain vocabulary information from the web services.

The controls provide vocabulary navigation, search and selection functionality that can be embedded directly within your own web pages. A set of associated demonstration pages show how to configure and use each widget control, and how to combine them to create functionally rich user interfaces.

This is a preliminary release of the widget controls, and hopefully they will serve as exemplars to engender discussion and additional ideas about what people might want to do with these vocabularies. The widget source code is available as Open Source, under a Creative Commons Attribution (CC-BY) arrangement. Try the widgets out and let us know how you get on – we welcome constructive feedback on how to improve and extend them!

Term suggestion, in a widget. What’s a widget?

Having the various vocabularies available online and accessible via web services we’re now in a position to create widgets (functional user interface controls) making use of the vocabularies. For this exercise we don’t really have to create anything new at all, just repurpose one of the nice examples from the jQuery UI site. We will create a type-ahead drop down autocompletion term suggestion control (à la Google), but employing domain specific vocabulary.

All SENESCHAL web services support JSONP callbacks allowing you to call them remotely to retrieve and display terminology from within your own web page. Our data source will be the SENESCHAL getConceptLabelMatch web service, and we will reuse elements of the JQUERY UI (remote JSONP) example. This example will keep the coding minimal for clarity, but of course you are free to introduce other bells and whistles as required. The first thing is to include references to the jQuery and jQueryUI scripts, and a basic stylesheet. So in your page header include the following lines:


<head>
<script src="http://code.jquery.com/jquery-1.11.0.min.js"></script>
<script src="http://code.jquery.com/ui/1.10.3/jquery-ui.js"></script>
<link rel="stylesheet" href="http://code.jquery.com/ui/1.10.3/themes/smoothness/jquery-ui.css" />
</head>

We will have a text box from which the term suggestions will drop down in response to typing, and a <div> element to display any selected suggestions as a link (I’ve used a bit of optional minor inline CSS styling here):


<body>
<input id="suggestions" style="width: 300px; border: 1px solid gray;margin-bottom: 3px;"/>
<br><label>Selected:</label><br>
<div id="selected" style="height: 200px; width: 300px; border: 1px solid gray; overflow: auto;"></div>
</body>

These elements should render something like the screen dump below:

seneschal.termsuggestion1

Now for the data source. The service call takes (among others) a ‘schemeURI’ parameter to specify the URI of a concept scheme the suggestions will originate from (URI is case sensitive). There is also a ‘startsWith’ parameter to search for labels that start with this text, or alternatively a ‘contains’ parameter. There is also an optional ‘limit’ parameter to specify the maximum number of records to return. Putting this together into an example gives us:

http://www.heritagedata.org/live/services/getConceptLabelMatch?schemeURI=http://purl.org/heritagedata/schemes/eh_period&startsWith=EARLY&limit=3

This call searches the periods list for the first 3 terms starting with “EARLY”. The response is a JSON array structure, containing the matching label, the label language and (importantly) the Linked Data URI for each concept:


[
{
"uri":"http://purl.org/heritagedata/schemes/eh_period/concepts/UM",
"label":"EARLY MED. OR LATER",
"label lang":"en"
},
{
"uri":"http://purl.org/heritagedata/schemes/eh_period/concepts/EM",
"label":"EARLY MEDIEVAL",
"label lang":"en"
},
{
"uri":"http://purl.org/heritagedata/schemes/eh_period/concepts/EIA",
"label":"EARLY IRON AGE",
"label lang":"en"
}
]

We now need to specify that the “#suggestions” element is to act as an autocomplete widget. The jQueryUI autocomplete control ‘minLength’ parameter controls how many characters are typed before it attempts a remote service call – we will use a value of 3. The ‘source’ parameter can either be a static JSON array structure in the format [{label: ‘abc’, value: ‘def’}] – or a function returning that format. We can encapsulate the service call into a Javascript AJAX call, and map the resultant data to the required structure. Finally the ‘select’ parameter is a function determining what to do when an item is selected from the drop down list of suggestions. So this time finding the first 5 terms containing the specified text from the periods thesaurus, within a <script> tag:

<script> 
$(function() {	
   $("#suggestions").autocomplete({
      source: function(request, response) {
         $.ajax({
            url: "http://www.heritagedata.org/live/services/getConceptLabelMatch", 
            cache: true,
            dataType: "jsonp",
            data: {            
               schemeURI: "http://purl.org/heritagedata/schemes/eh_period",
               contains: request.term,  
               limit: 5
            },          
            success: function(data) {
               response($.map(data, function(item) {              
                  return { label: item.label.toUpperCase(), value: item.uri }           
               }));
            }
         });
      },      
      minLength: 3,
      select: function(event, ui) { 
         if(ui.item) {
            $("<div>").html("<a href='" + ui.item.value + "'>" + ui.item.label + "</a>").prependTo("#selected");
            $(this).val(ui.item.label);					
         }
         else $(this).val("");
         return false;
      }  		
   });  
});  
</script> 

Now a set of suggestions should drop down after the 3rd character is typed into the upper text box (there may be a short delay for the service call to complete and return data). If we select any of these suggestions it is recorded into the lower box as a link containing the Linked Data URI of the selected concept, and the selected label fills the upper box. We could still ignore these suggestions, but this ‘progressive enhancement’ of the original text box allows us to offer selections from a controlled terminology without necessarily becoming intrusive or dictatorial about it.

seneschal.termsuggestion2

seneschal.termsuggestion3

Term suggestion, in a widget. A short example pulls this all together into a single HTML page. Feel free to download and experiment with it. Although this is a fairly simple example it is also quite powerful, as we can index data using the same domain specific vocabularies, referencing the same unique identifiers, from anywhere. Now try changing the ‘schemeURI’ parameter in the code to suggest terms from any of the other vocabularies hosted on HeritageData. Hopefully this has been a useful starting point that shows how you could incorporate SENESCHAL web service calls into your own systems.

Linked Open Data: a practical introduction for libraries, museums and archives – CIGS Event

The Cataloguing and Indexing Group in Scotland are hosting a seminar on Linked Open Data at the Edinburgh Centre for Carbon Innovation, High School Yards, Edinburgh  on Monday 18th November.  Peter McKeague will be giving a presentation on SENESCHAL from the perspective of a vocabulary owner.

For further details and registration (before 11th November), please visit the CIGs web page: http://www.cilips.org.uk/events/ and scroll down to Monday 18th November

 

 

 

How many beans make 5? or One man’s fish is another man’s poisson

As a little fella, I was often asked by my dad the somewhat perplexing question: “How many beans make 5?”. The even more perplexing answer, “a bean, a bean and a half, half a bean and 2 beans”,  is imprinted on my brain like the lyrics to every Rush song up to, but not including, Test For Echo (I blame the fact that this was the first album not to be released on vinyl and therefore I didn’t spend hours stroking the gatefold sleeve whilst reading the astonishing literary offerings of Mr N. Peart esq.). As ever, I digress.

The above answer is, indisputably, correct and for years I was as certain, as certain can be, that it was the definitive answer.

However…

In the early noughties, John Peel (DJ extraordinaire and National Treasure, RIP) asked the very same question on his BBC Radio 4 programme Home Truths. Imagine my surprise, dear reader, at

a) somebody else even knowing about the question

and

b) the staggering number of possible answers which his devout listeners sent in.

The debate seemed to go on for weeks and caused quite a kerfuffle amongst the cocoa-sipping, be-cardiganned denizens of Radio 4 land. Eventually, everyone had to agree to disagree.

Now, dear reader, I can hear you chuntering to yourself and muttering “What is this gibberish?”

Well, what this taught me was that sometimes there is no single definitive answer but that it doesn’t matter as long as everybody is aware that they’re discussing the same thing. Or in others words it doesn’t matter about the labels as long as the concept is agreed. That’s what we here at heritagedata.org are trying to bring about and the next step with the vocabularies that we have is to create links between them as a precursor to the development of the Uberthesaurus.

We’re also hoping to link to other vocabularies from our cousins across the channel and make a truly multi-lingual resource. So if you know of a vocabulary that’s out there then point it in our direction. Thank you for you co-operation in this matter.

Work in the pipeline

Publishing the vocabularies is the first phase in the immediate SENESCHAL project and broader work. More to follow later but briefly flagging up immediate plans.

Linking out
As good citizens of the LOD world, we want to make SKOS mapping connections both at the vocabulary level and more broadly connecting or collaborating with related projects. Currently there are a few mappings to Dewey linked data URIs, courtesy of a previous RCAHMW project. One obvious next step is publish SKOS mappings between the different national thesauri to each other and to the eventual uber thesaurus Phil has blogged about.

More broadly, making mappings between different language thesauri is also part of the ARIADNE archaeological infrastructure work we are involved in. This should also offer opportunities for other providers to make their vocabularies available as Linked Data.

Services
To help with the mappings, Ceri is working on alignment, as part of a larger body of work on RESTful web services that operate over the vocabulary Linked Data and facilitate their use. We plan to build on previous work with SOAP based services for STAR and develop more complex higher level services attuned to the immediate SENESCHAL use cases as a first step.

Widgets
Immediate applications of the services for SENESCHAL case studies include widgets for Browser based indexing applications.

Metadata
Thinking of possible users unfamiliar with the heritagedata website or who may not even know that the vocabularies exist, how can we help them discover, assess and perhaps decide to use or even extend the vocabularies? Part of the eventual solution (as usual) is metadata – this time at the vocabulary level.

We have included some initial vocabulary metadata (see the Properties at the top level of any of the Linked Data vocabulary schemes) though it is something we want to come back to and extend. For example, we’d like to include some metadata on the broad coverage of the vocabularies. Eventually we envisage vocabulary registries through ARIADNE and related projects where users may go to search for relevant vocabularies.

For this metadata we have made a start by using some metadata elements from the DCMI KOS Application Profile (DC AP) effort led by Marcia Zeng. This presents a core and extended set of metadata elements and we will be adding to our initial set of elements through discussions with the vocabulary providers.

In fact, it’s not so simple necessarily as assigning metadata to a vocabulary (though this is where we are starting). We might want to distinguish between a particular publication manifestation (eg linked data) of a particular language expression of an underlying work. And yes the DC AP builds on the FRBR work of the library community and provides different metadata elements for the different parts of the model. We have not chosen to model at that level currently but are interested in any views on this.

Cultosaurus Humongous or Everything you ever wanted to know about heritage but were afraid to ask

Big ideas

As mentioned in my earlier post – The thesaurus that time forgot – the idea of a combined Thesaurus of Monument Types for the whole of the UK has been around for more than a decade. Unfortunately, as with anything that’s left, unwatched, on a back burner for any length of time, it’s likely to boil over. In this case, like the magic porridge pot, the idea has not just boiled over, it has grown…and grown..and grown…and gr…(well you get the picture).

The idea is no longer to develop a UK-wide Thesaurus of Monument Types but to expand it to cover the whole of Cultural Heritage, and the whole of the geographic British Isles (including the UK, Ireland, Isle of Man and the Channel Islands).

The thesaurus would include those vocabularies provided by EH, RCAHMS and RCAHMW as well as bringing together all of the existing thesauri/authority files recommended by FISH.

In addition, it  would also look to incorporate other terminologies from the reference data lists in use by the following organizations:

Where practicable archaic, regional and dialect terms would be included and the thesaurus would include multilingual aspects with Welsh, Gaelic, Manx and Scots Gaelic included (where appropriate).

Why?

For both geographical and political reasons it is recognized that the UK, Ireland, the Isle of Man and the Channel Islands share a common cultural heritage with respect to their archaeology and architecture and that, although certain regional differences occur, these do not reflect the current geopolitical boundaries, for example:

  • The Neolithic monuments found across the whole area
  • The Roman presence in England, Scotland and Wales
  • The Viking settlements of Ireland, The Isle of Man, Scotland and the North of England
  • The Georgian architecture of Bath, Dublin and Edinburgh
  • The military architecture of the 18th, 19th and 20th Century

As such, the proposed British and Irish Thesaurus of Cultural Heritage (acronym not to be used in polite circles) aims to provide a common framework and language for the recording of the built and buried heritage.

What and how?

Currently the terminologies in use sit in isolation from one another. The intention of the TCH is to bring them together under the umbrella of an Uber-thesaurus. Thus each domain (monuments, objects, materials, periods etc.) will become a hierarchy within the larger Cultosaurus Humongous (to misquote Blue Oyster Cult).

This structure will also allow us to create relationships between domains so that if a monument type is made of a specific material and found in a specific period then we can model that within the structure.

Obviously once the TCH is built it will be made available as linked data, each concept being represented by a HTTP URI. It is also anticipated that we will be able to associate each concept with images and other documentation so that the TCH will become a truly encyclopaedic resource for the Cultural Heritage sector.

So, that should be simple enough then…