eFoundations

Write to Reply

I've noted before how much I like the Write to Reply service, conceived and developed by Tony Hirst and Joss Winn:

A site for commenting on public reports in considerable detail. Texts are broken down into their respective sections for easier consumption. Rather than comment on the text as a whole, you are encouraged to direct comments to specific paragraphs.

On that basis, I am very pleased to announce that we have made available a small amount of funding for the service, initially covering the website hosting costs for the next 6 months but with a commitment to do so in some form for 2 years (whether that be through a continuation of the current hosting arrangement or by moving the content to Eduserv servers or elsewhere).

It strikes me that Write to Reply has already demonstrated its value in various fields, notably in the areas of education and government policy, and I'm sure it will continue to do so. It's one of those ideas that is rather simple and obvious in hindsight, yet very powerful in practice - give people a public space in which they can make comments on important documents and make it social enough that commenting feels more like having a conversation than simply annotating a text.  Good stuff.  Long may it continue.

"Simple DC" Revisited

In a recent post I outlined a picture of Simple Dublin Core as a pattern for constructing DC description sets (a Description Set Profile), in which statements referred to one of the fifteen properties of the Dublin Core Metadata Element Set, with a literal value surrogate in which syntax encoding schemes were not permitted.

While I think this is a reasonable reflection of the informal descriptions of "Simple DC" provided in various DCMI documents, this approach does tend to give primacy to a pattern based solely on the use of literal values. It also ignores the important work done more recently by DCMI in "modernising" its vocabularies, emphasing the distinction between literal and other values, and reflecting that in the formal RDFS descriptions of its terms.

In a document presented to a DCMI Usage Board meeting at DC-2007 in Singapore, an alternative, "modern" approach to "Simple DC" was proposed by Mikael Nilsson and Tom Baker. (I don't have a current URI for the particular document, but it is part of the "meeting packet"). That proposal suggested a view of "Simple DC" as a DSP (actually, it proposed a DCAP, but I'm focussing here on the "structural constraints" component) in which the properties referenced are not the "original" fifteen properties of the DCMES, but rather the fifteen new properties added to the "DC Terms" collection as part of that modernisation exercise:

• A description set must contain exactly one description (Description Template: Minimum occurrence constraint = 1; Maximum occurrence constraint = 1)
• That description may be of a resource of any type (Description Template: Resource class constraint: none (default))
• For each statement in that description, the type of value surrogate supported depends on the range of the property:
  • For the following property URIs: dcterms:title, dcterms:identifier, dcterms:date, dcterms:description (Statement Template: Property List constraint):
    • There may be no such statement; there may be many (Statement Template: Minimum occurrence constraint = 0; Maximum occurrence constraint = unbounded)
    • A literal value surrogate is required (Statement Template: Type constraint = literal)
    • Within that literal value surrogate, the use of a syntax encoding sceme URI is not permitted (Statement Template/Literal Value: Syntax Encoding Scheme Constraint = disallowed)
  • For the following property URIs: dcterms:creator, dcterms:contributor, dcterms:publisher, dcterms:type, dcterms:language, dcterms:format, dcterms:source, dcterms:relation, dcterms:subject, dcterms:coverage, dcterms:rights (Statement Template: Property List constraint):
    • There may be no such statement; there may be many (Statement Template: Minimum occurrence constraint = 0; Maximum occurrence constraint = unbounded)
    • A non-literal value surrogate is required (Statement Template: Type constraint = non-literal)
    • Within that non-literal value surrogate
      • the use of a value URI is not permitted (Statement Template/Non-Literal Value: Value URI Constraint = disallowed)
      • the use of a vocabulary encoding scheme URI is not permitted (Statement Template/Non-Literal Value: Vocabulary Encoding Scheme Constraint = disallowed)
      • a single value string is required (Statement Template/Non-Literal Value/Value String: Minimum occurrence constraint = 1; Maximum occurrence constraint = 1) and the use of a syntax encoding scheme URI is not permitted (Statement Template/Non-Literal Value/Value String: Syntax Encoding Scheme Constraint = disallowed)

This pattern seeks to combine the simplicity of use of the "traditional" "Simple DC" approach of using only 15 properties with a recognition of the value of using literal and non-literal values as appropriate for each property. However, it is, by definition, slightly more complex than the "all literal values" pattern outlined in the earlier post, and it differs from the patterns described informally in existing DCMI documentation (and I think it would be difficult to argue that it is represented using formats like the oai_dc XML format, which of course predated the creation of the new properties by several years.)

This does not have to be an either/or choice. It may well be that there is a use for both patterns, and if they are clearly named (I don't really care what they are called as long as the names are different!) and documented, there is no reason why two such DSPs should not co-exist.

Having said all that, I'd just re-emphasise that I think both of these patterns are fairly limited in the sort of functionality they can support. It seems to me the notion of "Simple DC" emerged at at time when the emphasis was still very much on the indexing and searching of textual values, and it largely ignores the Web principle of making links between resources. It would be difficult to categorise "Simple DC" - in either of the forms suggested - as a "linked data" friendly approach. I fear a lot of effort has been spent trying to build services on the basis of "Simple DC" when it may have been more appropriate to recognise the inherent limitations of that approach, and to focus instead on richer patterns designed from the outset to support more complex functions.

P.S. I know, I know, I promised a post on "Qualified DC". It's on its way....

Virtual World Watch Request for Information

Over at Virtual World Watch, John Kirriemuir is embarking on collecting data for his seventh "snapshot" survey of the use of virtual worlds in UK Higher and Further Education, and has issued a request for updated information:

The question

How are you using virtual worlds (e.g. Second Life, OpenSim, Metaplace, OLIVE, Active Worlds, Playstation Home, Blue Mars, Twinity, Wonderland) in teaching, learning or research?

Things you may want to include:

• Why you are using a virtual world.
• If teaching using a virtual world, how it fits into your curriculum.
• Any evaluation of the experience of using the virtual world.
• Will you do it again next year? Why (or why not)?

Please send any response to John, by Tuesday 10 November 2009. For further information, see the post on the Virtual World Watch weblog.

This is me – now what was the question?

I note that the call for papers for the TERENA Networking Conference (TNC) 2010 is now out. Given that the themes focus (in part) on network lifestyle and identity issues I wondered about putting in something based on Dave White's vistors vs residents work (yeah, that again!). Something like the following:

The Web used to be seen as a tool to get various jobs done – booking a holiday, finding a train time, reading email, catching up on lecture notes, checking a bank account, and so on. The people using such tools adopted a largely visitor mentality, - they fired up their Web browser, undertook a task of some kind, and left. Little or no trace was left.

Over the past few years the Web has changed significantly. It is now a social space, as much a part of people's lives as going down the pub, going to work, or turning up for lectures. As a result, many people are now increasingly adopting a resident mentality – cohabiting a social networked environment with others and intentionally leaving a permanent record of their activities in that space.

In a world of visitors, the principle reason for asserting identity (“this is me”) is so that the particular tool being used can determine what an individual's access rights are. But in a world of residents, that is only part of the story. They are more likely to assert their identity as part of a “this is who I am”, this is what I’ve done”, this is who I know” transaction with other people in their social space.

The functional requirements of the identity infrastructure are therefore very different for residents than they used to be for visitors. SAML is geared to meeting the needs of visitors and the tools they wish to access. OpenID caters much more to a ‘resident’ way of thinking.

If we believe that the Web is changing us (as it certainly is), and particularly if we believe that the Web is changing learning and research, then we have to be prepared to change with it and adopt technologies that assist in that change.

Does that resonate with people?  I'd be interested in your thoughts.

SharePoint in UK universities event

We've just announced an event (in London on 25 November 2009) based on the work that's been done by Northumbria University (and others) as part of the Investigation into the Uptake and use of Microsoft SharePoint by HEIs study that we funded a while back.

• Do you want to learn about how and why HEIs are using SharePoint? What worked well, lessons learned?
• Do you want to hear from some HEIs about their experience of implementing SharePoint?
• Do you want the opportunity to network and learn about real experiences with SharePoint in HEIs and benchmark yourself?

The event will provide a chance to hear from the project team about their findings, as well as from 4 university-based case-studies (Peter Yeadon, UWE, University of Glasgow, and University of Kent).

Please go to the registration page to sign-up - places are limited.

Virtual worlds in UK HE - the 'which?' and the 'why?'

A new snapshot report is available from the Virtual World Watch project (funded by us), Choosing virtual worlds for use in teaching and learning in UK higher education, this one looking specifically at which virtual world platforms are being chosen by practitioners in UK universities and asking them why they made that choice.

Second Life and OpenSim were mentioned or used by most respondents.

Second Life is attractive due to its constant development over six years, there is no need to acquire a server or significant local technical support, the large community of experienced practitioners, and the variety of already-created objects and structures that can be quickly re-used cheaply or for free.

OpenSim is attractive because, compared to Second Life, ‘land’ does not carry the same expense, there are fewer security issues, there is no dependence on a single commercial vendor, and it is easier to configure how private your environment is; content can also be ported from Second Life.

Apart from Second Life and OpenSim, over a dozen other virtual worlds or environments were mentioned; of these Metaplace and Forterra’s OLIVE appeared to pique more interest and use, from an educational perspective, than the others. Some respondents had examined a range of virtual worlds. Sensibly, organisations such as St Andrews University are examining these from the perspective of the educational or project requirements, rather than the attributes of the particular virtual worlds.

It is clear from the report that carrying out a full evaluation of the available options is not a trivial undertaking, especially given the rate of change of technology in this area, leading to a situation in which some universities are defaulting to the two most obvious choices whilst others are in danger of replicating evaluation work already undertaken by others.

The report calls for more rapid sharing of the findings of evaluation work being undertaken across the sector, both so that the community as a whole is better informed and so that there is less danger of duplicated effort.

The ubiquitous university

(I have no idea what that title means by the way!)

We're thinking about topics for next year's Eduserv Symposium and the front runner right now (though, of course, things may well change) is to focus on some aspect related to ubiquitous computing, mobile devices, augmented reality, 'everyware', and the Internet of things.

Just a long list of buzzwords then I hear you cry?  Well, yes, maybe!

That said, it does seem to me that the impact of this particular set of buzzwords on universities (and other educational institutions) will be quite far-reaching... and therefore worth spending some time thinking about at a reasonably strategic level.  The immediate issue, for us, (and indeed, the reason for this blog post) is in choosing some kind of useful permutation of these topics to make for a reasonably focused, interesting, useful and, ultimately, well-attended symposium during May next year!

It strikes me that two aspects of these things are particularly interesting.

The first lies in pedagogy and, in particular on whether this growth in mobility (for want of a better phrase) lends itself to changes (for the better) in the way that learning and teaching happen in universities.

The second has to do with ownership and control.  As we move from a world in which universities provisioned ICT for their staff and students (services, software, hardware, and the network) to a world in which nearly all of that provisioning is, or at least can be, owned and controlled by the end-user, where does that leave the university as a provider of services?  In particular, where does it leave the role of IT Services departments?  Do they simply become a broker/facilitator between the end-user and a bunch of external providers?

Both areas look like potentially interesting topics and I'm minded to try and cover both on the day.  But I'd be very interested in hearing your views.  Does this look like a useful and interesting topic for our next symposium?  Have these issues been done to death elsewhere?  Would you attend (it is a free event followed by a very nice drinks reception after all!)?  Let me know what you think.  Thanks!

Helpful Dublin Core RDF usage patterns

In the beginning [*] there was the HTML meta element and we used to write things like:

<meta name="DC.Creator"content="Andy Powell">
<meta name="DC.Subject" content="something, something else, something else again">
<meta name="DC.Date.Available" scheme="W3CDTF" content="2009-10-19">
<meta name="DC.Rights" content="Open Database License (ODbL) v1.0">

Then came RDF and a variety of 'syntax' guidance from DCMI and we started writing:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.net/something">
    <dc:creator>Andy Powell</dc:creator>
    <dcterms:available>2009-10-19</dcterms:available>
    <dc:subject>something</dc:subject>
    <dc:subject>something else</dc:subject>
    <dc:subject>something else again</dc:subject>
    <dc:rights>Open Database License (ODbL) v1.0</dc:rights>
  </rdf:Description>
</rdf:RDF>

Then came the decision to add 15 new properties to the DC terms namespace which reflected the original 15 DC elements but which added a liberal smattering of domains and ranges.  So, now we write:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:foaf="http://xmlns.com/foaf/0.1/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.net/something">
    <dcterms:creator>
      <dcterms:Agent>
        <rdf:value>Andy Powell</rdf:value>
        <foaf:name>Andy Powell</foaf:name>
      </dcterms:Agent>
    </dcterms:creator>
    <dcterms:available
rdf:datatype="http://purl.org/dc/terms/W3CDTF">2009-10-19</dcterms:available>
    <dcterms:subject>
      <rdf:Description>
        <rdf:value>something</rdf:value>
      </rdf:Description>
    </dcterms:subject>
    <dcterms:subject>
      <rdf:Description>
        <rdf:value>something else</rdf:value>
      </rdf:Description>
    </dcterms:subject>
    <dcterms:subject>
      <rdf:Description>
        <rdf:value>something else again</rdf:value>
      </rdf:Description>
    </dcterms:subject>
    <dcterms:rights
rdf:resource="http://opendatacommons.org/licenses/odbl/1.0/" />
  </rdf:Description>
</rdf:RDF>

Despite the added verbosity and rather heavy use of blank nodes in the latter, I think there are good reasons why moving towards this kind of DC usage pattern is a 'good thing'.  In particular, this form allows the same usage pattern to indicate a subject term by URI or literal (or both - see addendum below) meaning that software developers only need to code to a single pattern. It also allows for the use of multiple literals (e.g. in different languages) attached to a single value resource.

The trouble is, a lot of existing usage falls somewhere between the first two forms shown here.  I've seen examples of both coming up in discussions/blog posts about both open government data and open educational resources in recent days.

So here are some useful rules of thumb around DC RDF usage patterns:

• DC properties never, ever, start with an upper-case letter (i.e. dcterms:Creator simply does not exist).
• DC properties never, ever, contain a full-stop character (i.e. dcterms:date.available does not exist either).
• If something can be named by its URI rather than a literal (e.g. the ODbL licence in the above examples) do so using rdf:resource.
• Always check the range of properties before use.  If the range is anything other than a literal (as is the case with both dc:subject and dc:creator for example) and you don't know the URI of the value, use a blank or typed node to indicate the value and rdf:value to indicate the value string.
• Do not provide lists of separate keywords as a single dc:subject value.  Repeat the property multiple times, as necessary.
• Syntax encoding schemes, W3CDTF in this case, are indicated using rdf:datatype.

See the Expressing Dublin Core metadata using the Resource Description Framework (RDF) DCMI Recommendation for more examples and guidance.

[*] The beginning of Dublin Core metadata obviously! :-)

Addendum

As Bruce notes in the comments below, the dcterms:subject pattern that I describe above applies in those situations where you do not know the URI of the subject term. In cases where you do know the URI (as is the case with LCSH for example), the pattern becomes:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.net/something">
    <dcterms:subject>
      <rdf:Description rdf:about="http://id.loc.gov/authorities/sh85101653#concept">
        <rdf:value>Physics</rdf:value>
      </rdf:Description>
    </dcterms:subject>
  </rdf:Description>
</rdf:RDF>

Open, social and linked - what do current Web trends tell us about the future of digital libraries?

About a month ago I travelled to Trento in Italy to speak at a Workshop on Advanced Technologies for Digital Libraries organised by the EU-funded CACOA project.

My talk was entitled "Open, social and linked - what do current Web trends tell us about the future of digital libraries?" and I've been holding off blogging about it or sharing my slides because I was hoping to create a slidecast of them. Well... I finally got round to it and here is the result:

Open, social and linked - what do current Web trends tell us about the future of digital libraries?

View more presentations from Andy Powell.

Like any 'live' talk, there are bits where I don't get my point across quite as I would have liked but I've left things exactly as they came out when I recorded it. I particularly like my use of "these are all very bog standard... err... standards"! :-)

Towards the end, I refer to David White's 'visitors vs. residents' stuff, about which I note he has just published a video. Nice one.

Anyway... the talk captures a number of threads that I've been thinking and speaking about for the last while. I hope it is of interest.

Description Set Profiles for DC-2009

For the first time in a few years, I'm not attending the Dublin Core conference, which is taking place in Seoul, Korea this week. I've been actively trying to cut back on the long-haul travel, mainly to shrink my personal carbon footprint, which for several years was probably the size of a medium-sized Hebridean island. But also I have to admit that increasingly I've found it pretty exhausting to try to engage with a long meeting or deliver a presentation after a long flight, and on occasions I've found myself questioning whether it's the "best" use of my own energy reserves!

More broadly, I suppose I think we - the research community generally, not just the DC community - really have to think carefully about the sustainability of the "traditional" model of large international conferences with hundreds of people, some of them travelling thousands of miles to participate.

But that's a topic for another time, and of course, this week I will miss catching up with friends, practising the fine art of waving my hands around animatedly while also trying to maintain control of a full lunch plate, and hatching completely unrealistic plans over late-night beers. Good luck and safe travels to everyone who is attending the conference in Seoul.

Anyway, Liddy Nevile, who is chairing the Workshop Committee (and has over recent years made efforts to enable and encourage remote participation in the conference), invited Karen Coyle and me to contribute a pre-recorded presentation on Description Set Profiles. We only have a ten minute slot so it's necessarily a rather hasty sprint through the topic, but the results are below.

Dublin Core Description Set Profiles (DC-2009)

View more presentations from Pete Johnston.

I think this is the first time I've recorded my own voice since I was in a language lab in an A-Level French class in 1990! To date, I've done my best to avoid anything resembling podcasting, or retrospectively adding audio to any of my presentation slide decks on Slideshare, mostly because I hate listening to the sound of my own voice, perhaps all the more so because I know I tend to "umm" and "err" quite a lot. And even if I write myself a "script" (which in most cases I don't) I seem to find it hard to resist the temptation to change bits and insert additional comments on the fly, and then I realise I'm altering the structure of a sentence and repeating things, and I "umm" and "err" even more... Argh. I'm sure I recorded every sentence of this in Audacity at least three times over! :-)