Can one desire too much of a good thing?

Image of spiced syrup cakes

An image of spiced syrup cakes – definitely too much of a good thing!

Our blog post title (from As You Like It (Act IV, Scene 1) reflects our desire for your feedback on our Will’s World Registry online hack event. We have had some fantastic comments back already – by email, Google+ and, mainly, via our survey – but we are still hoping for more!

Please do pass along the survey link, https://www.survey.ed.ac.uk/willsworldhack/, to friends, colleagues or any mailing lists or groupd you think may be interested in working with data on Shakespeare.

Whilst we begin the process of analysing surveys and other comments we did want to share a few interesting ideas of new ways to work with Shakespeare data that you have already told us about…

We’ve heard about some fantastic work, led by Faith Lawrence, to programmatically analyse Shakespeare’s work to see if it passes the Bechdel test, originally conceived as a test for movies in one of Alison Bechdel’s regular comic strips. A movie (or cultural object) passes the test if:  (1) it has to have at least two women in it, who (2) talk to each other, about (3) something besides a man. Of course for Shakespeare this throws up lots of interesting issues as his plays regularly feature characters cross dressing and playing with their gender and/or identity. Read more in Chris Gutteridge’s blogpost and Faith Lawrence’s paper presented at the Narrative and Hypertext Workshop, Hypertext 2011.

Meanwhile an email with a jokey comment about Christopher Marlowe had us wondering if comparing or analysing the Will’s World Registry with data on any of those who have, at some point, been rumoured to be the real author of Shakespeare’s work might throw up some interesting data… with that in mind we’d welcome any data sets you may have on Christopher Marlowe, Francis Bacon or Edward de Vere…

Wanted poster based on "Christopher Marlowe, dramatist, poet" by Flickr user lisby1 / Lisby   Wanted Poster based on "Sr Francis Bacon" by Flickr user Stifts- och landsbiblioteket i Skara / Skara kommun    Wanted Poster based on "Edward Vere, Earl of Oxford" by Flickr user lisby1 / Lisby

We’ve also had a number of really thoughtful responses on the practical considerations of running an online hack – some of the risks and opportunities around doing this. If you have any thoughts or concerns on the idea please do leave us comments, complete the survey or email us with any feedback.

In other news… we hear that we have inspired another hack event already!  The SPRUCE project folk spotted our tweet about a Will’s World online hack event and decided to set up their own one day remote hackathon, on 16th November, to make file format identification better (crucial for preservation). You can find more information about their #fileidhack on the event wiki.

And finally… if you find yourself in London next week then there is a special  Late: Shakespeare beyond the city taking place on Friday 2nd November, from 6pm until 9pm in the British Museum Great Court. A variety of creative interpretations of Shakespeare will be taking part with contributions from the National Theatre and RADA students and creative potential Will’s World Hackers will particularly be interested in the prop-making workshop.

Image credits for this post: 

Wanted poster and thumbnail version of wanted poster based on “Christopher Marlowe, dramatist, poet” by Flickr user lisby1 / Lisby; Wanted Poster based on “Sr Francis Bacon” by Flickr user Stifts- och landsbiblioteket i Skara / Skara kommun; Wanted Poster based on “Edward Vere, Earl of Oxford” by Flickr user lisby1 / Lisby

Share

Online Hack Event

Our Will’s World project is soon coming to an end. While we are busy populating the Shakespeare Registry with great data, we are keen to put this wonderful resource to good use. How can we achieve this in an unusual and fun way?

How about an online hack event!

The idea first came to us as we began planning a traditional hack event – something in person, overnight, possibly featuring pizza. As we started looking at how this would work best we realised there were lots of logistical issues to deal with from finding a suitable venue, to catering to the issue of how participants could find the time to travel and take part.

We also started to think about things that don’t always work so well in in-person hack days… sometimes the software you want to use is sitting on a machine you don’t have with you, sometimes you need to attend to caring responsibilities which just don’t fit into a 24 hour marathon lockdown, and sometimes you just can’t move that meeting or spare the travel time to fly miles away to make that fantastic looking hack day somewhere at the other end of the country.

And that’s when we realised that an online hack event might not only resolve our logistical issues but that the flexibility and potential benefits of an online hack event are also very exciting!

More people can participate:

  • Participants who wouldn’t be able to travel (whether because of the cost, time, distance, or scheduling conflicts) can easily join in.
  • The event can be scheduled to allow participants from further afield and different time zones to be included turning a local event into a global hack event.
  • There is no restriction on the number of participants due to the venue size or cost.

Enable use of familiar tools:

  • Participants can use their own machine, familiar set up and well-loved applications in their own environment. There is no need to get used to a different technical environment or to first install the tools you can’t do without. That means more time to be creative, to hack, play and collaborate.
  • Wifi and cable internet connections are also a lot more likely to be fast and reliable – at least something you are used to managing – if they are not being shared intensely by a room full of coders!
Keyboard disassembled and planted with cress

“Prepared keyboard waiting to sprout” by Flickr user wetwebwork

Flexibility in participation:

  • Participants can choose when and how much efforts they put in to the hack.
  • Participants can fit their participation around their other commitments.

Promote use of social media technologies:

  • Many collaboration tools can be used to run the event and connect people: blog, Twitter, wiki, Skype, Google Hangout, videos, websites…
  • Participants or those who find out about the event later can still share in the event with records of the hacks more easily captured via video, wikis, text chats etc.

Obviously,  the critical issue will be to ensure that communication takes place effectively during the hack between people scattered in various locations. Team formation will be interesting – but no weirder than grabbing a coke or a beer and introducing yourself around a room of fellow hackers. And we know that  interruptions could be tricky for some participants since they will be occupied with the Will’s World hack from their normal office or home desk. We can see challenges here but we think the benefits could make this a great format for our hack event.

But we want to know what YOU think of the idea…

We have come up with a few scenarios on how this type of online hack could work. We would really appreciate your help in evaluating different formats and communication tools for this event. Please take a moment to tells us what you think and provide us with your feedback by taking this short survey:

https://www.survey.ed.ac.uk/willsworldhack/

Please do feel free to share that survey link with others you think might be interested in this event. We also welcome any comments here as well.

Shakespeare's Globe Theater, Southwark, London

Image based on “Shakespeare’s Globe Theater, Southwark, London” by Flickr User nikoretro/Sheri

One last thing, we are aiming for the online hack to take place during the first week of December. Put it in your diary!

Share

SPARQL – What’s up with that?

The title of this post is intended to convey a touch of bewilderment through use of a phrase from the Cliff Clavin school of observational comedy.

Linked data and SPARQL

In the linked data world, SPARQL (SPARQL Protocol and RDF Query Language) is touted as the preferred method for querying structured RDF data. In recent years several high profile institutions have worked very hard to structure and transform their data into appropriate formats for linked data discovery and sharing, and as part of this, many have produced RDF triple (or quadruple) stores accessible via SPARQL endpoints – usually a web interface where anyone can type and run a SPARQL query in order to retrieve some of that rich linked data goodness.

This is admirable, but I have to admit to having had little success getting something out of SPARQL endpoints that I would consider useful. Every time I try to use a SPARQL facility I find I do better by scraping data from search results in the main interface. I have also increasingly become aware that I am not the only one to find it difficult.

RDF stores are different to relational databases; they are not so amenable to performing a search over the values on a particular field. Nor are they as flexible as text search databases like Solr. Instead they record facts relating entities to other entities. So it is important that as consumers of the data we know what kind of questions make sense and how to ask them in a way that yields useful results for us and does not strain the SPARQL endpoint unduly. If these are not the kind of questions we want to ask then we might need to question the application of SPARQL as the de facto way of accessing RDF triple stores.

I’d like to point out that my aim here is not to complain or to disparage SPARQL in general or anybody’s data in particular; I think it is fantastic so many institutions with large archives are making efforts to open up their data in ways that are considered best practice for the web, and for good reasons. However if SPARQL endpoints turn out to be flawed or inadequately realised, they will not get used and both the opportunity to use the data, and the work to produce it, will be wasted.

Problems with SPARQL endpoints

These are the problems I have commonly experienced:

  • No documentation of available vocabularies.
  • No example queries.
  • No access to unique identifiers so we can search for something specific.
  • Slowness and timeouts due to writing inefficient queries (usually without using unique ids or URIs).
  • Limits on the number of records which can be returned (due to performance limits).

Paraphrasing Juliette Culver’s list of SPARQL Stumbling Blocks on the Pelagios blog, here are some of the problems she experienced:

  • No query examples for the given endpoint.
  • No summary of the data or the ontologies used to represent it.
  • Limited results or query timeouts.
  • SPARQL endpoints are not optimised for full-text searching or keyword search.
  • No link from records in the main interface to the RDF/JSON for the record. (This is mentioned in relation to the British Museum, who provide a very useful search interface to their collection, but don’t appear to link it to the structured data formats available through their SPARQL endpoint.)

Clearly we have experienced similar issues. Note that some of these are due to the nature of RDF and SPARQL, and require a reconception of how to find information. Others are instances of unhelpful presentation; SPARQL endpoints are generally pretty opaque, but this can be alleviated by providing more documentation. With the amount of work it takes to prepare the data, I am surprised by how few providers accompany their endpoints with a clear list of the ontologies they use to represent their data, and at least a handful of example queries. This takes a few minutes but is invaluable to anybody attempting to use the service.

Nature provide the best example I have seen of a SPARQL endpoint, providing a rich set of meaningful example queries. Note also the use of AJAX for (minimal) feedback while query is running, and to keep the query on the results page.

Confusion about Linked Data

A blog post by Andrew Beeken of the JISC CLOCK project reports dissatisfaction with SPARQL endpoints and linked data, and provoked responses from other users of linked data:

“What is simple in SQL is complex in SPARQL (or at least what I wanted to do was) … You see an announcement about Linked Data and don’t know whether to expect a SPARQL endpoint, or lots of embedded RDF.” Chris Keene

“SPARQL seems most useful for our use context as a tool to describe an entity rather than as a means of discovery.” Ed Chamberlain

Chris’ point gives another perspective on linked data in general – what does it mean to provide linked (or should that be linkable) data, and how do we use it? Embedded RDF (RDFa) is good in that it tends to provide structured data in context, enriching a term in a webpage in a way that is invisible by default but that people can consume if they choose to. Ed indicates a fact about RDF as a data storage medium: it is a method of representing facts about entities which are named in an esoteric way; it is not structured in a way that is ideal for the freer keyword searching or SQL-style queries that we are used to.

Owen Wilson suggests the Linked Data Book‘s section 6.3 which describes approaches to consuming linked data, describing three architectural patterns. It looks worth a read to get one thinking about linked data in the right way.

Unique identifiers

“My native English, now I must forego” Richard II, Act 1, Scene 3

One of the tenets of linked data is that each object has a unique identifier. If we are looking for “William Shakespeare” we must use the URI or other identifier that represents him in the given scheme, rather than using the string “William Shakespeare”. It is thus also necessary that we have an easy way to access the unique identifiers that are used in the data, so that we can ask questions about a specific entity without forming a fuzzy, complex and resource-consuming query. The British Museum publicises its controlled terms, that is the limited vocabulary that they use in describing their collection, along with authority files which provide the canonical versions of terms and names, standardised in terms of spelling, capitalisation and so on, and thesauri which map synonymous terms to their canonical equivalents. These terms are used in describing object types, place names and so on, supporting consistency in the collections data. They are all available via the page British Museum controlled terms and the BM object names thesaurus. Armed with knowledge of what words are used in particular fields to categorise or describe entities in the data, and similarly with a list of ids or canonical names for things, we can then start to form structured queries that will yield results.

Shakespeare and British Museum

I have looked in particular at the British Museum’s SPARQL endpoint as an example, as BM is a project partner and because it has several items germane to Will’s World. To start with, the endpoint gives some context; a basic template query is included in the search box, which can be run immediately and which implicitly documents all the relevant ontologies by pulling them in to define namespaces. There is a Help link with some idea of how data is represented and can be accessed/referenced using URIs. All of this is good and I found it easy to get started with the endpoint.

However before long I came up against the problem I’ve had with other endpoints, namely that it is difficult to perform a keyword search, or at least perform a multi-stage search in order to (a) resolve a unique identifier for a keyword or named thing and then (b) retrieve information about or related to that thing. In this case I found a way to achieve what I needed by supplementing my usage of the SPARQL endpoint with keyword searches of the excellent Collection database search – and with some help from the technical staff at BM to resolve a couple of mistakes in my queries, can now harvest metadata about objects related to the person “William Shakespeare”.

It is reassuring to find out I am not alone in having difficulty retrieving and using SPARQL data. I followed Owen Stephen’s blog post about the British Museum’s endpoint with interest. Owen found the CIDOC CRM data model hard to query due to its (rich, but thereby counter-intuitive) multi-level structure. Additionally, he encountered the common issue that it is very difficult to perform a search for data containing or “related to” a particular entity which to start with is represented merely by a string literal such as “William Shakespeare”:

The difficulty of exploring the British Museum data from a simple textual string became a real frustration as I explored the data – it made me realise that while the Linked Data/RDF concept of using URIs and not literals is something I understand and agree with, as people all we know is textual strings that describe things, so to make the data more immediately usable, supporting textual searches (e.g. via a solr index over the literals in the data) might be a good idea.

Admittedly RDF representations and SPARQL are not really intended to provide a “search interface” in the sense to which most users are accustomed. But from the user’s perspective, there must be an easy way to start identifying objects about which we want to ask questions, and this  tends to start with performing some kind of keyword search. It is then necessary to identify the ids representing the resulting objects or records which are of interest. With the BM data this involves mapping a database id, which can be retrieved from the object URL, to the internal id used in the collections.

So what are the right questions?

Structured data requires a structured query – fair enough. However what sort of useful or meaningful query can we formulate when the data, the schema used to represent the data, the identifiers used within the data, are all specified internally? In order to construct an access point into the data, it is helpful to have not just a common language, but a common (or at least public) identifier scheme; canonical ways of referencing the entities in the data, such as “Shakespeare” or “the Rosetta Stone”. Without knowing the appropriate URI or the exact textual form (is it “Rosetta Stone”, “The Rosetta Stone”, “the Rosetta stone”? would we get more results for “Rosetta”?) it is nigh on impossible to easily ask questions about the entity of a SPARQL endpoint.

So how is one supposed to use a SPARQL endpoint? It is not a good medium for asking general questions or performing wide-ranging searches of the data. Instead it seems like a good way to link up records from different informational silos (BM, BL, NLS, RSC…) that share a common identifier scheme. If we know the canonical name of a work (“Macbeth”) or the ISBN of a particular edition, then we can start to link up these disparate sources of data on such entities.

But the variety of translations, the plurality of editions (which will only increase) and other degrees of freedom make it hard to perform an exhaustive analysis/usage of the data. In the case of the BM, who might have unique objects we don’t know we want to see, the way to find them is through keyword search. It seems that only by going first through a search interface or other secondary resource can we identify the items we want to know about and how to refer to them.

What we have in common between different sources is the language or ontologies used to describe the schema (foaf, dc, etc) – but this is syntax rather than semantics; structure rather than content. To echo Ed Chamberlain’s comment, we have access to how data is described, but not so much to the data itself.

 

British Museum data

The approach we will use to harvest British Museum metadata related to Shakespeare is outlined below. It is essentially the same approach that Owen Stephens found workable in his post on SPARQL, and involves reference to a secondary authority (the BM collection search interface) to establish identifiers.

  1. Conduct a search for “Shakespeare” in the collections interface.
  2. Extract an object id from each result. The Rosetta Stone has the id 117631.
  3. Find the corresponding collection id from SPARQL with this query:
    SELECT * WHERE { 
       ?s <http://www.w3.org/2002/07/owl#sameAs> 
          <http://collection.britishmuseum.org/id/codex/117631> 
    }
  4. The result should be a link to metadata describing the object, and the object’s collection id (in this case YCA62958) can be extracted for use in further searches.
    http://collection.britishmuseum.org/id/object/YCA62958
  5. If there is a result, retrieve metadata about the object from the URL: http://collection.britishmuseum.org/description/object/YCA62958.rdf (or .html, .json, .xml)
  6. If there is no result, scrape metadata from the object’s description page in the collections interface. There is plenty of metadata available, but it is far less structured than RDF, being distributed through HTML.

This last step looks like it will be quite common as many of the Shakespeare-related results are portraits or book frontispieces which have no collection id. I am not sure whether this is an omission, or because they are part of another object, in which case it will require further querying to resolve the source object (if that is what we want to describe).

Another difficulty is that although Owen found a person-institution URI for Mozart, I cannot find one for Shakespeare. There is a rudimentary biography but little else, so we do not have a “Shakespeare” identifier for use in SPARQL searches.

Conclusion

Ultimately I am still finding it non-trivial and a bit hacky to identify, and ask questions about, the real Shakespeare through a SPARQL endpoint.

Click here to view the embedded video.

In summary:

  • SPARQL endpoint providers could provide more documentation and examples.
  • RDF stores allow us to ask structural questions, but semantic questions are much harder without knowing some URIs.
  • It is often necessary to make use of a secondary resource or authority in order to identify the entities we wish to ask about.

Share

Asimov’s Guide to Shakespeare

We were planning to make the book chapter on Macbeth from the Asimov’s Guide to Shakespeare available for Culture Hack Scotland but unfortunately we ran out of time. Although the text for this book is readily available in PDF and other formats, there was no usable format for programmers to easily work with and mash with other content. We set out to mark up the text using a combination of automated and manual processing to create a useful version in XML which lends itself to computer processing. Information and the text itself have been added to the data page for Culture Hack Scotland.

The marked up text of Macbeth supplied to Culture Hack Scotland was very successful at inspiring the creative programmers taking part including the team winning the top prize with their Shakey app: a Massively Multiplayer, Real Time, Macbeth Parlour game. This Asimov text complements the Macbeth text so well that it would have been a shame to keep it to ourselves. Hopefully, it will fuel further imaginative developments now and at future hack events.

 

Share

Will’s World at Culture Hack Scotland

This weekend saw the Culture Hack Scotland event take place at SocietyM in Glasgow. Culture Hack Scotland gathers creative people including developers, designers, artists and creative practitioners and supports them to work together over an inspiring and intense 24 hour period of idea sharing, data hacking and creativity.

The materials we have been scoping for the Will’s World registry seemed like a fantastic potential data source for this event, particularly given that it was taking place in the week of the 448th anniversary of Shakespeare’s birth.  We got in touch with the CHS team and after a bit of discussion about what might be appealing to CHS developers and what could be delivered in the time available, it was decided that we would be an official Data Partner for Culture Hack Scotland 2012 providing a marked up version of Macbeth. This would be the full text provided in XML and included various valuable additions to the data that would enable a greater array of possibilities for creative use of the text and/or aggregation with further resources.

Is this a data set I see before me?

Around a week before the event we were able to provide a link to a new data page containing the full text of Macbeth which had been beautifully marked up, including details on characters and locations (including lat/longs added through Unlock), prepared by our software engineer, Neil Mayo. Our colleagues from the Statistical Accounts of Scotland and JISC MediaHub services also made their metadata available (linked from the same page) to enable CHS participants to connect the play to related resources such as historical notes on counties mentioned in the text, or video recordings of key performances.

We sent off the data and it was featured in the weekly update for announcing data provided for the event. There were four of these Data Thursdays in all offering a staged announcement of all of the CHS data, each one announced with the release of data slices enabling developers to have a look and a play with the data ahead of the event. The last Data Thursday included a fantastic mention for the Macbeth data and, as it went live, all of us in the Will’s World team took a deep breath and nervously crossed our fingers that someone would be taking a look, having ideas, and, hopefully building something fantastic…

Who comes here?

Friday evening saw the kick off the event and the gathering of around 100 people including developers of all types, designers, artists, musicians and data owners for the kick off of Culture Hack Scotland.  The event opened with an introduction from the Culture Hack Team and an inspiring pair of talks from James Stewart, Technical Architect for data.gov.uk and Brigitta Zics, Head of Digital Media / Convenor of Creative Digital Practice Group for Culture Lab at Newcastle University.

As the evening continued all hack participants were encouraged to share any early ideas they might have to get conversations going and teams forming, and we were delighted to hear at least one possible Macbeth project emerging right away. As the event moved into the team formation and hacking time it became clear that several projects were really excited about the idea of working with the Macbeth data. A number of developers who were looking at working with Macbeth complemented the quality of the XML we had provided for CHS making us ever so proud and extra excited about the possibilities for using this data.

The night has been unruly where we lay

The true business of hacking only really kicked off late in the evening but by midnight a hardcore team of hackers were working, in teams or alone, on a range fascinating ideas and projects. At the 2.30am catch up – a meeting with a lot of coffee and around 30 committed CHS hackers – it became clear that some really creative work was underway: one team had taken a pair of old skinny jeans and were in the process of using Arduino hardware to create a very alternative way to experience The Skinny magazine’s arts listsings; a mobile developer was creating a new interface for Glasgow Museum’s Zoology collections data; one team had already finished a map interface for crowdsourced stories. However for the Will’s World team the most exciting thing was finding out about three projects who had decided to work with the Macbeth data in very different ways: one focusing on the emotions of the text; one building an interactive game; and one looking at how Macbeth and social media could be combines. Indeed Nicola Osborne, who was along at the hack representing Will’s World and EDINA, had gotten involved in one of these projects by creating some Monty Python-esque illustrations for the interactive game team.

Illustrations of characters from SketchyApp

CHS participants carried on working through the night, sustained by never ending supplies of coffee, chocolate and fruit. A few naps were taken but by early Saturday morning – when this CHS piece featuring the Macbeth data appeared in The Herald – even more teams were working away as those who could not make the Friday began to appear, full teams gathered after sleeping in shifts, and the final push to finish off ideas and hacks got under way.  The submission deadline for hacks was 4pm ready for a show and tell session of epic proportions with some 29 presentations of over 35 hacks waiting to be showed off.

CHS article in Saturday 28th April's Herald Newspaper

When shall we three meet again

In the end a total of three teams had worked with the Macbeth XML. They were:

Shakey App

Shakey App is a Massively Multiplayer, RealTime, Macbeth Parlour game. It was designed by the team of Rory Fitzpatrick (@roryf), James Newbery (@froots101), Philip Roberts (@phillip_roberts) & Padmini Ray-Murray (@praymurray). With additional stage design, by Duich McKay and character illustrations by Nicola Osborne.

Shaky App as demonstrated in their Show & Tell Presentation

The way that Shakey App works is that players login and randomly assigned a part to play. They are then prompted with the lines via their phones and the audience around them (who also have to be logged in) can then vote on the best and worst performances by virtually hurling tomatoes in horror or throwing flowers in appreciation. It was demoed live at CHS as pictured above and you can read a full write-up  or take a look at the code for the project.

Screenshot from ShakyApp

Colouring Macbeth In a Glass Case Of Emotion 

Douglas Greenshields (@bedroomation) created this inventive exploration of the Macbeth text through the emotions of the text. The user is presented with a number of extracts from the play and asked about the one that feels most… something… that might be “fearful” or “angry” or “loving”, etc. Each of those emotion questions is coloured a certain way, fear might be green for instance. When you click on the extract that is the most of that emotion the text is coloured appropriately and over time the system builds up an idea of which scenes connect emotionally, how the readers emotion is reflected in their marking up of the text, etc. Click through to the Colouring Macbeth In a Glass Case of Emotion site to have a go and read Douglas’ account of what he has created to find out more.

Macbeth Digital 

The team of Marius Ciocanel (@MariusCiocanel), David MacKenzie and Minka Stoyanova decided to create their own Twitter client pulling in the Macbeth text as tweets from each of the characters. “Tweets” are timed to come in at a great reading pace and you can use buttons at the top of the page to switch between scenes.

Screenshot from Macbeth Digital

Screenshot from Macbeth Digital

 

These projects gave us some fantastic opportunity to think about some really creative uses for Shakespeare data and metadata and we were pleased that colleagues from the Royal Shakespeare Company, who are currently running the incredible World Shakespeare Festival 2012, had also been able to make it to the CHS Show & Tell and see these projects showcased.

We were inspired not only by the Macbeth projects but also by the other hacks showcased at CHS as there were some fantastic ideas from music made from footfall data to ambitious games built from poetry – full details of all of the projects created at the event are now available on the Culture Hack Scotland site.  Chatting with developers and designers throughout the event and at the Show and Tell highlighted some really useful reflections and comments around the need for quality data and the opportunities and challenges of aggregating large data sets. We will certainly be bearing in mind those perspectives as we move forwards.

Is that my prize?

Once all of the projects had presented at the Show & Tell the judging took place. We are delighted to say that Shakey App, built on the Will’s World Macbeth data, was awarded the honour of Most Playful Hack and went on to take the Overall Grand Prize Winner!

The team behind the Grand Prize Winner Shakey App.

The team behind the Grand Prize Winner Shakey App.

When the hurlyburly’s done 

Now that Culture Hack Scotland has been and gone what happens next?

Well we plan to keep the Macbeth XML available and would love to see any new ways to hack/use/create things from any of the data we made available from CHS. The page will remain live and we will be adding some additional data that complements the Macbeth XML shortly. If you do decide to create something new we would love to hear about it – leave a comment here or drop us an email us via edina@ed.ac.uk.

Culture Hack Scotland cup cake

 

Share

Culture Hack Scotland

A first glimpse of Will’s World will be given at the Culture Hack Scotland 2012 event taking place in Glasgow on April 27th and 28th. Culture Hack Scotland is a fast-paced and highly creative event that challenges designers, technologists and artists to make innovative new culture-related projects in just 24 hours.

To give it a Scottish twist, EDINA has put together some content around the text of Macbeth to kick start some data discovery and aggregation of metadata from digital resources relating to William Shakespeare. We are hoping this will provide the seeds for some original and exciting new developments focused around Shakespeare’s works.

A resource page is available here.

Share

Welcome to Will’s World

Welcome to Will's World

Will’s World is a  JISC Discovery project in which EDINA aims to demonstrate the value and principles of aggregation as a tactic. The concept behind this project is that assembling online data sources relating to one topic will add value and improve the discoverability of these resources; making it easier for developers and service providers to build services and ultimately providing an easier access for all to the data itself and enriched content based on it.

Will’s World is an example of the aggregation as a tactic approach applied to the world of William Shakespeare. EDINA will design, build and populate a Shakespeare Registry of metadata of digital resources relating to Shakespeare covering anything from its work and live to modern performance, interpretation or geographical and historical contextual information. Application Programming Interfaces (APIs) will be provided to allow efficient machine to machine interaction with the registry. APIs will allow the owners of digital content on Shakespeare to advertise their resources by registering and depositing their metadata and the details of the APIs to their data. APIs will enable the developers to work and access content from various sources more easily and efficiently.

Will’s World will demonstrate the value of metadata enhancement through the creation of a showcase application using the aggregated data available in the registry. Additional tools such as text mining or geo tagging will be used to enhance the data and bring various data formats together.

Will’s world will document and disseminate the process of building this prototype registry to allow other to use and benefits from our findings in order to build similar registries centred around other topics.