So, what’s in linked datasets for education?

18 Apr 2012 at 22:02

Mathieu

Datasets, overview

2 Comments

Since the first push when we deployed data.open.ac.uk, the area of linked data for education, especially in universities, as been slowly but steadily growing. This is obviously a rather good news as a critical benefit of linked data in education (some would say, the only one worth considering) is that it creates a common, public information space for education that goes outside the boundaries of specific institutions. However, this will only happen if a certain level of convergence is happening so that shared vocabularies and schema elements are commonly used that make it possible to aggregate and jointly query data provided by different parties. Here, we try to get an overview of the current landscape in existing linked datasets in the education sector, to see how much of this convergence is happening, what are the areas of clear agreement, and the ones where more efforts might be required.

The Datasets

To look at the current state of linked data in education, we considered 8 different datasets, some provided by universities and some by specific projects. We looked at datasets that were explicitly dedicated to education (as opposed to the ones containing information that could be used for educational purposes, such as library and museum data, and the ones that have connection with education but focus on other aspects, such as the datasets from purely research institutions). Also, we view datasets in a very coarse-grained way, for example considering the whole of data.open.ac.uk as one dataset, rather than each of its sub-datasets separately. Finally, we could only process datasets with a functioning SPARQL endpoint working properly with common SPARQL clients (in our case ARC2).

From Universities:

  • data.open.ac.uk which SPARQL endpoint is available at http://data.open.ac.uk/sparql
  • data.bris from the University of Bristol. SPARQL endpoint: http://resrev.ilrt.bris.ac.uk/data-server-workshop/sparql
  • University of Southampton Open Data. SPARQL endpoint: http://sparql.data.southampton.ac.uk/
  • LODUM from the University of Muenster, Germany. SPARQL endpoint: http://data.uni-muenster.de/sparql

Others should be included eventually, but we could not access them at the time

From projects and broader institutions

  • mEducator, a european project aggregating learning resources: SPARQL Endpoint: http://meducator.open.ac.uk/resourcesrestapi/rest/meducator/sparql
  • OrganicEduNet a european project that aggregated learning resources from LOM repositories (see this post). SPARQL endpoint: http://knowone.csc.kth.se/sparql/ariadne-big
  • LinkedUniversities Video Dataset which aggregates video resources from various repositories (see this paper). SPARQL Endpoint: http://smartproducts1.kmi.open.ac.uk:8080/openrdf-sesame/repositories/linkeduniversities
  • Data.gov.uk Education which aggregates information about schools in the UK. SPARQL endpoint: http://services.data.gov.uk/education/sparql

Common Vocabularies

As everybody will always say: the important thing is the reuse shared and common vocabularies! As they are talking about similar things, it is expected that education-related datasets would share vocabularies, and that their overlaps would allow to achieve joint reuse of the exposed data. The chart above shows the namespaces that are used by more than one of the considered datasets.

Unsurprisingly, FOAF is almost omnipresent. One of the reasons for this is that FOAF is the unquestioned common vocabulary to represent information about people, and it is quite rare that an education-related dataset would not need to represent information about people. It is also the case that FOAF includes high-level classes that are also very common, especially in this sort of datasets, namely Document and Organisation.

In clear second place come vocabularies to represent information about bibliographic resources, and other published artifacts: Dublin Core and BIBO. Dublin Core is actually the de-facto standard for metadata for just about anything that can be published. BIBO, the bibliographic ontology, is more specialised (and actually rely on both Dublin Core and FOAF) to represents in particular academic publications.

Other vocabularies used include generic “representation languages” such as RDF, RDFS, OWL and SKOS (often used to represent topics), as well as specific vocabularies related to the description of multimedia resources, events and places (including building, addresses and geo-location).

Common Classes

At a more granular level, it is interesting to look at the types of entities that can be found in the considered datasets. The chart above shows the classes that are used by at least 2 datasets. This confirms in particular the strong focus on people and bibliographic/learning resources (Article, Book, Document, Thesis, Podcast, Recording, Image, Patent, Report, Slideshow).

In second place come information about educational institutions as organisations and physical places (Organization, Institution, Building, Address, VCard).

Besides generic, language-level classes other areas such as events, courses, vacancies, etc. tend to be only considered by a very small number of datasets.

Common Properties

Finally, going a step further in granularity, we look through the chart above at the way common types of entities are represented. This chart show the properties used by more than 3 datasets. Once again, besides generic properties, the focus on people (name) and media/bibliographic resources (title, date, subject) is obvious, especially with properties connecting the 2 (contributor, homepage).

The representation of institutions as physically located places is also clearly reflected here (lat, long, postal-code, street-address, adr).

Doing More with the Collected Data

Of course, the considered datasets only represent a small sample, and ideally, we could draw some more definitive conclusions as the number of education-related datasets grows and are included. Indeed, in order to realise the analysis in this post, we created a script that generates VOID-based descriptions of the datasets. The created descriptions are available on a public SPARQL endpoint which will be extended as we find more datasets to include. Please let us know if there are datasets you would like to see taken into account. The charts above are dynamically generated out of SPARQL query to the aforementioned SPARQL endpoint.

Also, we will look at reflecting the elements discussed here on the vocabulary page of LinkedUniversities.org. The nice thing about having a SPARQL endpoint for the collected data is that it will make it easy to create a simple tool to explore the “Vocabulary Space” of educational datasets. This might appear useful as well as a way provide federated querying services for common types of entities (see this recent paper about using VOID for doing that), which might end-up being a useful feature for the recently launched data.ac.uk initiative (?) Another interesting thing to do would be to apply a tiny bit of data-mining to check for example what elements tend to appear together, and see if there are common patterns in the use of some vocabularies.

Transforming Legacy Data into RDF – Tools

13 Feb 2012 at 14:42

Mathieu

overview

4 Comments

As part of the extension of the project, I was talking recently with Sean Bechhofer, who is currently looking at doing some linked data for the University of Manchester. A part of the discussion was naturally concerned with reusing things from LUCERO. One thing Sean would have expected to be able to reuse are the tools we employed/developed for extracting data from their original sources into RDF. While many parts of the LUCERO technical workflow are reusable, and the extractors are only a small part of it, it is still quite disappointing that these tools are not based on generic mechanisms that can be easily re-applied to other environments, especially because tools to extract RDF from legacy data exist.

This post is therefore meant as a bit of a survey on such tools, their scope and applicability. There are different types of tools that can be considered, depending in particular on the format of the original source.

Generating RDF from Relational Databases

Triplify is one of the first tools we experimented with, in a pilot project that was based on a relational (MySQL) database. The way to use Triplify, if it is not already integrated as a plugin for whatever you are doing, is to defined a set of SQL select queries on the database, that also include information about the way the results should be converted into RDF. More precisely, it is assumed that each row of results correspond to an individual, that the first column is an identifier for individual, and other columns are properties. A simple example of such a query is: SELECT id,name AS 'foaf:name' FROM users. This works very well for simple, easy to transform structures, but tends to become difficult to manage when the RDF graph has to be significantly different from the naive transformation of the database (with queries spanning over many queries, or RDF individuals being contributed to by many tables).

D2RQ takes a slightly different approach to Triplify, as instead of trying to create an RDF dump of a relational database, it allows to create a mapping that relate the structure of the database to RDF triples, and transforms at run-time SPARQL queries into SQL queries using this mapping. The D2RQ mapping language is reasonably simple, as shown in the example below, and can express many intricate relationships from the database. Another advantage is that the D2RQ tool can create a default ‘naive’ mapping from the database schema, which can then be customized (therefore facilitating the first steps of managing the transformation process). In case of evolving databases, the mapping can become quite hard to maintain however. Another disadvantage is that the run-time query transformation approach is not very efficient (but help keeping data up-to-date). It is worth noticing however that D2RQ can also create an RDF dump of the content of the database using the same mapping.

map:Conference a d2rq:ClassMap;
d2rq:dataStorage map:Database1.
d2rq:class :Conference;
d2rq:uriPattern "http://conferences.org/comp/confno@@Conferences.ConfID@@";
.
map:eventTitle a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:Conference;
d2rq:property :eventTitle;
d2rq:column "Conferences.Name";
d2rq:datatype xsd:string;
.
map:location a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:Conference;
d2rq:property :location;
d2rq:column "Conferences.Location";
d2rq:datatype xsd:string;
.

ODEMapster is based on the R2O mapping language, which, similarly to the one of D2RQ, can establish relations between the structure of a database and the way it can be exported into RDF. ODEMapster however focuses more on the creation of OWL ontologies from the content of databases. It is available currently as a plugin of the NeOn Toolkit for Ontology Engineering. Similarly, RDVToOnto tries to semi-automatically extract populated ontologies, relying on both the schema of and content patterns in the database.

It is worth noticing here as well that the W3C has set-up an RDB2RDF working group, in charge in particular of defining a common language, set of requirements and test cases for transforming relational databases (RDB) into RDF. The working group has in particular produced a survey of existing approaches in this area.

Generating RDF from XML (including RSS)

There have been less work on converting XML sources into RDF than converting from relational databases. One of the reasons, paradoxically, is that XML and RDF share a common base, at least in terms of syntax (i.e., RDF/XML uses an XML syntax, XML can be made, somehow, RDF friendly and RSS 1.0 is, in principle, already in RDF). There have therefore been quite a few examples of syntactic conversions of XML to RDF/XML, using in particular XSLT.

The GRDDL language recommended by the W3C intends to provide a standard and systematic way to achieve such XSLT based transformation, by making it possible to declare that XML documents include data compatible with RDF. It has been extensively used for example for the conversion of microformats.

Generating RDF from tables and spreadsheets

In many domains, including ours, data simply come in tabular format, through spreadsheets and CSV files. Transforming such formats, intended to make the data easily sharable between people, can be quite a challenge.

Google Refine is a tool which is meant as an easy way to clean, transform and explore data in a tabular format. It can import from many different sources, including MS Excel, Google Spreadsheet and CSV, and includes a number of useful features to work on the data. While it is not originally developed to support RDF export, it is extensible. The RDF Extension has been created in order to allow export into RDF (with a graphical definition of the mappings between the table and RDF), as well as to including useful tools to connect the content of the table to external linked datasets.

Other tools exist such as Any23 or QUIDICRC that provides simple, direct transformation of CSV files into RDF.

More specific sources and generic frameworks

There are many other tools that exist that can be used legacy data into RDF, from small specific tools, to generic frameworks (see http://www.w3.org/wiki/ConverterToRdf for a more complete list).

For example, SIMILE RDFIzer is a set of specialized converters for a large variety of input formats. Of relevance to the education domain, we can for example notice marcmods2rdf which converts library catalog records to RDF, oai2rdf which can extract RDF from open archive repositories (OAI-PMH) and ocw2rdf which can extract RDF from MIT OpenCourseWare metadata.

Even outside RDFIzer, a number of converters can be found that would take as input specialized formats and export them into RDF using particular vocabularies. We can mention for example Bibtex2RDF converting bibliographical references in the Bibtex format, or the Youtube2RDF tools developed in the LUCERO project, and that converts Youtube playlists into RDF using media vocabularies.

Conclusion

As can be seen from above, one can sometimes find many options to convert legacy data into RDF, depending on the original format of the data, and on the particular requirements regarding the transformation process. This list is obviously not complete.

One the main issue however regarding the use of these tools is not the choice, but rather their integration and adaptation into the right environment. Some tools would require efforts into creating and maintaining a mapping between the original source and RDF, which might end-up being very time consuming (possibly more than creating dedicated, ad-hoc converters like we did in LUCERO). Other converters do not require such configuration, but would produce ‘generic RDF’ that might not fit the considered requirements. Some might say for example that a generic conversion of MARC to RDF is inconceivable. Finally, when having to convert from many different sources with disparate formats, managing the use of multiple tools, their outputs (and especially the overall consistency of the produced RDF) and their scheduling might become a difficult challenge.

LUCERO extension

23 Nov 2011 at 12:31

Mathieu

Project Activities

No Comments

We have had quite a few nice new things happening in relation to LUCERO recently, including some updates of the code, initial work around aggregating data from multiple universities, a paper at a linked data workshop with people from several departments of the OU, presentations, etc. In other words, the work is continuing, and quite a lot more will be happening soon. In turns out indeed that we have not spent all of our budget and have some more time to spend on synthesising, factoring and making more directly reusable the work we have done as part of the project (don’t ask me how that happened…).

The idea here is therefore, starting from February 2012, to work on making our experience in LUCERO, in creating data.open.ac.uk, more directly accessible and reusable by other universities and colleges. The exciting bit about it is that, while we have been working mostly internally for the initial duration of the project, we will realise this new work in direct collaboration with two other universities: one that has already achieved a similar realisation as our own data.open.ac.uk (Southampton, working with Christopher Gutteridge), and one that is at the first, very initial steps of the process (Manchester, working with Sean Bechhofer).

More precisely, here is a quick description of the work, divided in workpackages:

WP1: Technical/Conceptual/Organisational process of deploying linked data in a University

The goal of this workpackage is to rely on our (joint) experience to describe and provide some guidelines regarding the different options related to the deployment, maintenance and sustainability of a linked data platform in a University. This includes in particular tasks such as the choice of vocabularies for data modelling, or the ways to establish links between internal and external datasets.

Deliverable: Report/Guidelines describing the concrete steps of deploying linked data in a university.

Duration: 12 days

WP2: Business case for linked data in universities

Nowadays, everything is driven by business cases and nothing happens with the direct approval and support from higher management. In this workpackage, we will compile a collection of common case studies demonstrating the benefits of linked data (whether it is to drive innovation, reduce cost of data management or create new entry points to the university’s online presence), and providing clear demonstrations of the business value of linked data.

Deliverables:A clearly illustrated, online collection of case studies with associated business cases for linked data in universities.

Duration: 12 days

WP3: Liaison with other universities involved in linked data

This workpackage contains the work related to the collaboration with other universities, including the organisation of face-to-face and online meetings, capturing their experiences and requirements, etc.

Deliverable: Meeting reports and descriptions of other universities’ linked data environments in comparison with data.open.ac.uk

Duration: 5 days

WP4: Dissemination and community portal

In this workpackage, we will rely on the experience in LUCERO in the use of blogs and twitter feeds to realise the dissemination of the results of the work. We will also make use and extend the LinkedUniversities.org portal to host the reports, guidelines and business cases produced as part of the work, and engage with the community around this documentation.

Deliverables:Extensions of the project blog, twitter feed and of the linkeduniversities.org portal

Duration: 5 days

Final Product Post: Tabloid

01 Jul 2011 at 09:04

Mathieu

Project Activities

No Comments

This is the final, formal post of the LUCERO JISC project. However, be reassured, this is far from the last post. More and more activities around linked data are happening at the Open University, and this blog will carry on being a primary channel for communication and discussions around these activities.

For this post, we had to chose one “product” of the project, which we believed was to be most useful and reusable by others. We have done so many things over the last year that choosing one was almost impossible. After a lot of discussion and head scratching, we decided to promote as a product our collection of tools, examples and documentions, explaining the why and how of linked data, as well as the benefit one can get from deploying linked data in a higher education institution. We call this toolkit Tabloid: Toolkit ABout Linked Open Institutional Data.

Users

To clarify very quickly, the intended target audience for the Tabloid Toolkit are not the end-users of linked data. We focus here on helping people in higher education institutions with getting involved in promoting, implementing and deploying linked data within their institution. This includes more or less anybody who would have a role to play in the management of data and information, from PVCs to researchers, librarians and developers.

Overview

Tabloid is an evolving toolkit made of code, documentation and examples in various places, and trying to address the people with various roles involved in the deployment of linked data: from managers who want to quickly understand the benefits, to developers who are expected to work with it, develop applications and integrate it into their technical workflow.

In this sense, Tabloid can be seen an entry point to institutional linked data, with different parts being relevant to different people at different times. It includes many components distributed in different ways, and put together in a coherent structure in the Tabloid Page. In particular, the toolkit contains documentations giving an overview of the basic principles of linked data, of the way it concretely creates benefits and of simple examples of how such benefits can be exploited in research and education scenarios (see What is linked data?). It provides an overview of both the technical and organisational workflows that are necessary to deploy linked data in an institution, and provide some tool support to realise common tasks in such workflows. Finally, Tabloid puts a particular emphasis on the aspect of using and consuming linked data, providing documentation and experience reports regarding the use of linked data. It includes many pointers to a large variety of applications developed within the LUCERO project, together with reusable source code.

Link: The Tabloid page

LUCERO blog up to 1st July 2011:

Many parts of the Tabloid toolkit described above have been drawn out or described in blog posts on the LUCERO Blog. Here we give a brief overview of the content of the blog according to (mostly emerging) categories of posts:

Publishing Datasets

One of the major activities in LUCERO is related to the exposure as linked data of a number of datasets from the Open University. The posts in this category explain and describe how we realised such exposure for a number of datasets.

Documentation and Support

The LUCERO blog is also used to provide easily accessible documentation regarding various aspects of the project. This category contains posts and pages that are intended to help people to better understand the principles and technologies related to linked data.

Tools and Applications

This category includes posts that describe tools and applications developed within the project. It is an important part of the activities in LUCERO, demonstrating through examples how one can benefit from linked data, and how to realise such applications.

Experience report – Guest posts

One great success of LUCERO is that it has managed to get people outside the project and the linked data community to engage with linked data, create applications of it and generally use the linked data we exposed for a variety of tasks. The posts in this category show a few of such examples.

  • ROLE Widget Consumes Linked Data – This guest post from a member of the ROLE project explains how linked data available on data.open.ac.uk was used to create a widget for the learning environment created by ROLE.
  • Know Thyself – This post written by a member of the communication services of the Open University shows how the availability of linked data can be used to quickly answer unexpected queries that aggregate resources from various resources.
  • Putting Linked Data to Work: A Developer’s Perspective – This guest post written by a developer from the IT department of the Open University demonstrates how linked data can be used and integrated to write new and more cost effective applications, despite the initial confusion that linked data technologies often create.
  • Introducing LUCERO – This post summarises the effort realised at the beginning of the project to explain and discuss with a large variety of people the expected benefits of linked data.

Project Plan

The 7 first posts on the blog gave the details of the project plan.

Hello World – This un-categorised post summarised, at the very beginning of the project, our expectations and plans for LUCERO.

Description of the Project

What to ask linked data

24 Jun 2011 at 15:54

Mathieu

Tools

2 Comments

Publishing linked data is becoming easier, and we now come across new RDF datasets almost everyday. One question that keeps being asked however is “what can I do with it?” More or less everybody understand the general advantages of linked data, in terms data access, integration, mash-up, etc., but getting to know and use a particular dataset is far from trivial: “What does it say? What can I ask it?”

You can look at the ontology to get an idea of the data model used there, send a couple of SPARQL queries to `explore’ the data, look at example objects. etc. We also provide example SPARQL queries to help people getting the point of our datasets. Of course, not everybody is proficient enough in SPARQL, RDF-S and OWL to really get it using this sort of clues. Also, datasets might be heterogeneous in the representation of objects, in the distribution of values, or simply very big and broad.

To help people who don’t necessarily know/care about SPARQL `getting into’ a complex dataset, we developed a system (whatoask) that automatically extract a set of questions that a dataset is good at answering. The technical aspects of realising that are a tiny bit sophisticated (i.e., it uses formal concept analysis) and are detailed in a paper I will present next week at the K-CAP conference. What is interesting however is how such a technique can provide a navigation and querying interface of top of a linked dataset, providing a simple overview of the data and a way to drill down to particular areas of interest. In essence, it can be seen as an FAQ for a dataset, not presenting frequently asked questions, but the questions the dataset is specially good at answering.

What the tool does is creating a hierarchy of all the simple questions an RDF dataset can answer, and presents to the user a subset that, according to a set of metrics described in the paper, are believed to be more likely of interest. The questions are displayed in a pseudo natural language, in a format where for example “What are the (Person/*) that (knows Tom) and that (KMi hasEmployee)?” can be interpreted as the question “What are the people who know Tom and are employed in KMi?”. Questions can be selected, and displayed with their answers, and the question hierarchy can be navigated, selecting more specific and more general questions than the selected one.

To clarify what that means, let’s look at what it does on the data.open.ac.uk OpenLearn dataset. The initial screen shows a list of questions, the first one (“What are the (Document/*/OpenLearnUnit) that (subject Concept, relatesToCourse Course, relatesToCourse Module)?”, i.e., “What are the OpenLearn Units that are related to courses and have a topic?”) being selected. More general and more specific questions are also shown, such as “What are the OpenLearn Units that have a topic?” (more general) and “What are the OpenLearn Units that relate to a course and have for topic `Education Research’?” (more specific).

We can select alternative questions, such as the second in the list — “What are the OpenLearn Units in english distributed under a creative commons licence and that talk about Science?”, obtain a new list of answers (quite a few), as well as more general and more specific questions. We can then specialise the question to “What are the OpenLearn Unit in english under a CC licence that talk about science and family?” and carry-on with a more general question looking at the `family topic’ without science, to finally ask “What are the OpenLearn units about family?” (independently of the licence and language).

As can be seen from the example, the system is not meant for people who know in advance what they want to ask, but to provide a level of serendipitous navigation amongst the queries the dataset can answer, with the goal of giving a general overview of what the dataset is about and what it can be used for. The same demo is also available using the set of reading experiences from the RED dataset and the datasets regarding buildings and places at the OU. The interface is not the most straightforward at the moment, but we are thinking about ways by which the functionalities of the system could be integrated in a more compelling manner, as a basic `presentation’ layer on top of a linked dataset.

PRONOM and linked data

26 May 2011 at 17:59

Mathieu

Datasets

No Comments

PRONOM is the national archive’s technical registry, and is currently being `transformed’ to be exposed as linked data. We can of course only welcome such an initiative and be very enthusiastic about this potentially valuable resource. Now, because we are of this kind of people who like to criticize (or more seriously, because we were asked by our programme manager to give feedback), here are a few comments regarding things that could be done better.

Most of the description and technical specification of the work relate to the specification of a vocabulary. Apart from all the low-level boring issues (such as “it is in pdf”, “it is not really clear”, etc.), there are major issues in its definition: mostly, 1- it is not really good modelling, and 2- it does not reuse enough other vocabularies. Funnily enough, these two criticisms could be applied to many vocabularies that are created `ad-hoc’, for a particular project.

A nice big example of bad modelling regards all the classes used to represent file formats. First, their names are quite seriously misleading. Video, is not a Video, it is a video type of file format. GIS is the type of file format use by a geographic information system, etc. I really don’t understand how these things could be classes. It seems that the intension was that a class such as `Video’ would correspond to what should be called `VideoFormat’. In this case for example <http://reference.data.gov.uk/id/file-format/13>, which corresponds to the PNG image format should be an instance of <http://reference.data.gov.uk/technical-registry/formatType/Image_(Raster)>. However, it is not. It is connected to it through a triple {<http://reference.data.gov.uk/id/file-format/13> <http://reference.data.gov.uk/technical-registry/formatType> <http://reference.data.gov.uk/technical-registry/formatType/Image_(Raster)>}, in which case, <http://reference.data.gov.uk/technical-registry/formatType/Image_(Raster)> should really be an individual (and have another name, e.g., <http://reference.data.gov.uk/technical-registry/formatType/raster-image-format>). Now, if that wasn’t confusing enough, <http://reference.data.gov.uk/id/file-format/13> is also a class. This one, I have no explanation for. I don’t know either why things such as <http://reference.data.gov.uk/technical-registry/Big_endian> are described as properties.

I’m sure there are quite a few other issues (even if the vocabulary seem in itself rather simple, but I haven’t found the RDF-S version of it), including underspecified domains, ranges and classes, untyped objects, etc. I might have missed something, but the naming conventions used seem to have been made voluntarily confusing. The four core classes are not capitalised, and use `-’ as separators. The other classes are capitalised and use `_’. Some properties would be fully in upper-case (MIMETYPE), some have the first letter capitalised and some only the first letter of the second word capitalised (and not word separator). The file formats are associated with numbers in the namespace ‘http://reference.data.gov.uk/id/file-format/’ while a human readable ID (e.g. ‘png1.2′) could have easily been created. Other things such as `internal signatures’ are also associated to numbers, in name spaces such as ‘http://reference.data.gov.uk/technical-registry/internalSignature/’. I never understand why many people seem to want to have ‘id’ in their namespaces, but if it is done for one, they might as well do it for the others. `Big_endian’ as mentioned above has a nice capital letter for the first word, not the second, while it is described as a property and used as an individual.

Finally, this vocabulary does not reuse. Almost nothing. The example promotes the use of the dublin core vocabulary. A tiny bit of SKOS is used for labels (I’m personally not too sure whether you could use SKOS label properties on things other than SKOS concepts, but that it is really only a detail). DC could certainly be used more (e.g., dct:published instead of releaseDate?). I’m also reasonably convinced that the W3C Ontology for Media Resources should be at least connected to this vocabulary.

In a nutshell, I like this vocabulary and the data based on it, and I will use them. They provide a great resource illustrating how easy it is to make wrong modelling choices.

wayOU – mobile location tracking app using linked data

23 May 2011 at 21:08

Mathieu

Tools

5 Comments

As can be seen from the few previous posts on this blog, one of our main focus at the moment is, in addition to trying to handle with all the data that we still have to process, to develop applications that demonstrate the benefit and the potential of linked data. When we obtained data from our estate department regarding the buildings and spaces in the Open University’s main campus (in Milton Keynes) and in the 13 regional centers, we got quite excited. The data contain details of the buildings and surroundings of the buildings (car parks, etc.) with their addresses, floors, spaces, images, etc.

However, these data was not very well connected. We used links to the postcode unit descriptions from the address to the ordnance survey dataset, giving us an general view on the locations of buildings (and so allowing us to build a very crude map of OU buildings in the UK), but we didn’t have precise locations of buildings. We also couldn’t relate the buildings with events (e.g., tutorials), people (through their workplace, attendance, etc.)

We therefore decided to build an application to not only use these data, but also create some of these missing relations, and specially, to allow OU users to connect to the data.

The application is called wayOU, for “where are you in the OU?”. It can be used to “check-in” at specific locations indicating the “reason” for attending these locations, to keep track of the different places where the user has been, declare the current location as his / her workplace, as well as to connect to their network at the Open University, in terms of the people they share activities with. The video below explains the principle of the application better than I can do with text.

The application is now being tested and is made available for download (see QR code below – without guaranty that it will actually work) on data.open.ac.uk. Fouad is going to demonstrate it next week at the Extended Semantic Web Conference next week (see the abstract of the demonstration), and (perhaps more importantly) the sources of this first release are available in our code base.

qrcode

Publishing OpenLearn metadata as linked data

21 Apr 2011 at 08:51

Mathieu

Datasets

No Comments

OpenLearn is a website giving free access to Open University course material. We especially look at the “LearningSpace” where hundreds of HTML documents, called OpenLearn Units, are made available. These units represent very valuable resources for students as they provide entry points into specific topics, useful in particular in deciding whether or not to enroll in a course on this topic. A lot of these units relate directly to specific courses as their content is obtained from the corresponding course material. Being able to query and use such metadata in connection with other sources of information can be very useful in applications supporting students in the discovery of learning resources, as demonstrated by the OpenLearn Linked Data application developed by Fouad Zablith.

Representing an OpenLearn unit is realised through a specific class called OpenLearnUnit, which is a subclass of foaf:Document. Most of the common fields, such as title, subject and description of the unit are represented through common Dublin Core properties. A specific property relatesToCourse is used to relate a unit to the corresponding course in the Course Description dataset. We also use the Creative Commons Rights Expression vocabulary to express the license attached to the content of the unit (mostly Creative Commons Attribution – NonCommercial-ShareAlike 2.0 Licence) and the Nice Tag Ontology to connect units to the keywords they have been tagged with.

While all this information is already available in structured form from the OpenLearn websites (through XML descriptions and RSS feeds), having it in directly accessible, Web addressable and queryable makes it easier to create new interfaces, new links and new processess that facilitates the use of this information for resource discovery. Some elements are still being investigated, regarding in particular the complex connection that might exist between an OpenLearn unit and the corresponding course material as described in the library catalogue.

ROLE Widget Consumes Linked Data

14 Apr 2011 at 11:04

fouad

Tools, news

3 Comments

This is a guest post by Alexander Mikroyannidis, a researcher at the Knowledge Media Institute of The Open University, discussing the use of http://data.open.ac.uk to identify related material to OpenLearn units within a Moodle block.

The winning application of the KMi Linked Data Application Competition has attracted the interest of the ROLE project (Responsive Open Learning Environments – www.role-project.eu). The OpenLearn Linked Data application was originally developed by Fouad Zablith as a showcase of querying data.open.ac.uk for educational resources related with OpenLearn courses. I have now transformed this application into a widget that can be directly embedded into any OpenLearn course as a Moodle block. The widget displays a list of Open University courses, iTunesU podcasts, as well as OpenLearn tags related to the course that the user is currently viewing. As data.open.ac.uk is constantly growing by integrating metadata from more repositories, the widget will also be extended with recommendations about educational resources of additional types. You can try out the current release by logging in as guest at: http://projects.kmi.open.ac.uk/role/moodle/course/view.php?id=3.


This widget is part of the widget bundles developed by ROLE for providing self-regulated learning support. ROLE is aiming at empowering learners for lifelong and personalised learning within a responsive open learning environment. OpenLearn comprises one of the project’s test-beds concerning the transition from formal learning towards informal learning, where the learner is in control of the whole learning process. For more information about the learning technologies developed so far by ROLE, please visit the Showcase Platform (http://www.role-showcase.eu/).

Results of the KMi Linked Data Application Competition

24 Mar 2011 at 15:36

Mathieu

Tools, news

No Comments

One of the biggest worry we had at the beginning of LUCERO was that we were promising quite a lot: we were not only going to establish the processes to expose public university data as linked data, but also to demonstrate the benefit of it through applications. Originally, we naively thought that we were going to build two demonstrators, providing obvious and complete illustrations of the ways in which linked data could support students and researchers in better accessing information from the university, and better exploit it. We quickly discovered that this “killer app” approach wasn’t going to work, as the benefits of linked data appear to be a lot more in the many “day-to-day” use cases, rather than in large, “clever” application projects. In other words, as clearly shown in both Liam’s post and Stuart’s post, data.open.ac.uk is quickly becoming an essential resource, a piece of the information infrastructure, that benefits use cases, scenarios and applications of all sorts and scales.

That’s when we thought of organising a linked data application competition in KMi. KMi is full of very smart people, researchers and PhD students with the skills, knowledge and energy to build this sort of apps: lightweight, web or mobile applications to demonstrate one specific aspect and one specific use of the Open University’s linked data. I’m not going to give all the details of the way the competition was organised. We received four incredibly interesting applications (the promise of winning an iPad might have helped). This four applications are now featured on the brand new Data.open.ac.uk Application Page together with other applications currently being developed.

So, congratulations to our winners! The choice was really difficult (and you might not agree with it), as the applications described below are all great examples of the many things that can be achieved through opening up and linking university data.

The Winner: OpenLearn Linked Data (Fouad Zablith)

OpenLearn Linked Data makes use of data from data.open.ac.uk to suggest courses, podcasts and other OpenLearn units that relate to an OpenLearn Unit. The application takes the form of a bookmarklet that, when triggered while browsing the webpage of an OpenLearn unit, will add to the page small windows with links to the relevant course in Study at the OU, to podcasts from the OU podcast repositories and units from OpenLearn that share a common tag.

The great thing about this application is that it addresses scenarios directly relevant to students, prospective students and users of OpenLearn in general. It very naturally exploits the way linked data removes the boundaries that exist between different systems within the Open University, without having to change or integrate these systems.

Second Place: OU Expert Search (Miriam Fernandez)

The OU Expert Search system (accessible inside the OU network only) allows users to find academics at the Open University who are experts in a given domain, providing a ranked list of experts based in particular on their research publications. It uses information about publications in ORO and computes complex measures to provide a ranking of the people who are most likely to be experts in the given domain. It also integrates data obtained from the staff directory of the Open University to provide contact details for the people in the system.

Here as well the strong point of the application is its apparent simplicity. It is very easy to use and has been applied already for example to find Open University experts on Volcanoes (see Stuart’s blog post). Expert search is a complex task, and OU Expert Search, through the use of linked data, makes it look rather simple.

OUExperts (Vlad Tanasescu)

OUExperts is a mobile (android) application to find Open Univeristy experts in a given domain, and connect to their social network. Similarly to the OU Expert Search application, it relies on information related to the scientific publications of OU researchers, as available in ORO. It also finds synonyms of the given keywords, and tries to connect to the pages of the listed researchers.

The interesting aspect of OUExperts, apart from being a mobile application, is the clever attempt to connect to social networking website, so that it is not only possible to find an expert, but also to connect to them on Facebook or LinkedIn.

Buddy Study (Matthew Rowe)

Buddy Study suggests potential contacts and Open University courses to follow for students, based on the analysis of the topics in the user’s Facebook page. The application attempts to extract from the user’s Facebook page prominent topics, which are then matched to the interests of other people, and to the topics covered by courses at the Open University.

In this case, it is the social aspect of a user’s presence online which is used to create connections into the data from the Open University, creating easily accessible entry points to the data.

← Older Entries