« September 2009 | Main | November 2009 »

October 27, 2009

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.

October 22, 2009

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.

October 20, 2009

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.

October 19, 2009

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>

October 14, 2009

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:

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.

October 12, 2009

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.

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! :-)

October 09, 2009

Theatron 3 - final report

Theatron3 The final report from the Theatron 3 project is now available.

Theatron 3 was one of the projects that we funded under our 'virtual world' grants call in 2007 - seems like a long time ago now!

The project's objectives were twofold: firstly, to construct replicas of 20 historic theatres in the virtual world of Second Life (led by the Kings Visualisation Lab, King’s College London) and, secondly, to use those theatres as the basis for various sub-projects investigating the pedagogical value of 3D virtual worlds (led by the HEA English Subject Centre and HEA Subject Centre for Dance, Drama and Music).

The project has, I think, been very successful in the first aim, somewhat less-so with the second - but one of the things I really like about the final report is the honesty with which this is reported. We always said to the project that we wanted them to share what went wrong as well as what went right because it is only by doing so that we can move forward. On that basis, I repeat the summary of the final report here and I would urge those with an interest in virtual worlds to read the report fully:

  1. Second Life is a suitable environment for creating accurate and complex structures and embedding related pedagogical content. Build times can be greatly reduced through effective workflow plans.
  2. During the lifetime of the project, Second Life was too unreliable and presented too many barriers to institutions for full testing pedagogically. It is an appropriate medium for educational innovators, but early adopters will find that there are still too many issues for incorporating it into their practice.
  3. Immersive virtual worlds as a medium present many challenges to students, particularly due to cultural attitudes and the absence of embodiment experienced by some students. The time required to invest in learning to use the environments also is a barrier to adoption. For these reasons, it may always be problematic to make the use of immersive virtual worlds mandatory for students.
  4. As a medium for studying and communicating, Second Life presents many opportunities. As a performance medium it is limited when attempting to place existing, real life performance in a different medium, but has much potential when used to explore new forms of expression.
  5. The introduction of Second Life at institution often reveals many weaknesses in those institutions’ technical and service infrastructure. These inadequacies need to be resolved before widespread adoption of these technologies can occur.
  6. Immersive virtual worlds are a relatively new technology in education, and there was little understanding of the barriers to implementation within an institution and their most appropriate application to learning when the project started. Second Life itself needed much development in terms of reliability. In the intervening two years, there have been many steps forward in understanding its application to education. The technological goals of the project were well timed in this development cycle, but in retrospect the pedagogical aims were set too early, before the capabilities and limitations of the medium were sufficiently understood. However, the lessons learned pedagogically from Theatron will be invaluable in informing future practice.

I'll end with a quote from Professor Richard Beacham of the Kings Visualisation Lab, one of the project directors:

We think virtual worlds are here to stay and are getting ready to set up residence within them. We have a number of projects in progress and in prospect, primarily in Roman buildings and housing. We are adding Noh theatre and have Noh performers in collaboration with Japanese colleagues. We are excited and also grateful that the project gave us the chance to hit the ground running and to very quickly take a lot of materials which had the potential to be incorporated into a project like this and it's given us a real head start. It's put us somewhere towards the front of the pack and that’s a very good place to be.

This is very gratifying. We always took the view that Second Life was not necessarily an end in itself. Rather that its use in highly innovative and experimental ways could provide a stepping stone to greater understanding and, potentially, to other things.

[Image: Theatre at Epidaurus, Greece - borrowed (without permission) from the Kings Visualisation Lab gallery.]

October 08, 2009

Multi-factor authentication

PayPal users will probably know this already but for some time now it has been possible to double-lock your PayPal account with an SMS Security Key, meaning that as well as having to give your email address and password to sign in you also have to type in a random 6-digit code sent to your mobile phone via SMS. This combination of something you know (your password) and something you have (your mobile phone) is intended to increase the security of the service.

I was initially rather sceptical that this would work, being under the impression that SMS is inherently unreliable, but it actually seems fine. OK, I'm not the world's biggest PayPal user - I probably sign in once a week at most - but, so far, I've not suffered lock-out because the SMS message with my 6-digit code in it didn't arrive quickly enough.

I'm surprised that more banks don't offer this feature for their online banking? (Actually, I don't use that many banks! But I can say that mine doesn't.)

I also noticed today that Amazon Web Services offer a similar multi-factor feature (which I think is reasonably recent), but using dedicated hardware rather than your mobile phone and SMS.

Finally, I note that MyOpenID.com offer CallVerifID, which will call your mobile when you try and sign in - though it is not currently available in the UK (because of the call costs).

All of which is largely anecdotal - I assume there are plently of other examples I could/should have cited, these just happen to be the ones I've noticed/used - but it strikes me that the use of the mobile phone as a second authentication device has some significant advantages (for the user at least) over a dedicated device.  As Will McInnes noted at FOTE last week, we all keep our mobiles close to us pretty much all the time now anyway.

October 07, 2009

What is "Simple Dublin Core"?

Over the last couple of weeks I've exchanged some thoughts, on Twitter and by email, with John Robertson of CETIS, on the topic of "Qualified Dublin Core", and as we ended up discussing a number of areas where it seems to me there is a good deal of confusion, I thought it might be worth my trying to distill them into a post here (well, it's actually turned into a couple of posts!).

I'm also participating in an effort by the DCMI Usage Board to modernise some of DCMI's core documentation, and I hope this can contribute to that work. However, at this point this is, I should emphasise, a personal view only, based on my own interpretation of historical developments, not all of which I was around to see at first hand, and should be treated accordingly.

The exchange began with a couple of posts from John on Twitter in which he expressed some frustration in getting to grips with the notion referred to as "Qualified Dublin Core", and its relationship to the concept of "DC Terms".

First, I think it's maybe worth taking a step back from the "Qualified DC" question, and looking at the other concepts John mentions in his first question: "the Dublin Core Metadata Element Set (DCMES)" and "Simple Dublin Core", and that's what I'll focus on in this post.

The Dublin Core Metadata Element Set (DCMES) is a collection of (what DCMI calls) "terms" - and it's a collection of "terms" of a single type, a collection of properties - each of which is identified by a URI beginning http://purl.org/dc/elements/1.1/; the URIs are "in that namespace". Historically, DCMI referred to this set of properties as "elements".

Although I'm not sure it is explicitly stated anywhere, I think there is a policy that - at least barring any quite fundamental changes of approach by DCMI - no new terms will be added to that collection of fifteen terms; it is a "closed" set, its membership is fixed in number.

A quick aside: for completeness, I should emphasise that those fifteen properties have not been "deprecated" by DCMI. Although, as I'll discuss in the next post, a new set of properties has been created in the "DC terms" set of terms, the DCMES properties are still available for use in just the same way as the other terms owned by DCMI. The DCMES document says:

Implementers may freely choose to use these fifteen properties either in their legacy dc: variant (e.g., http://purl.org/dc/elements/1.1/creator) or in the dcterms: variant (e.g., http://purl.org/dc/terms/creator) depending on application requirements. The RDF schemas of the DCMI namespaces describe the subproperty relation of dcterms:creator to dc:creator for use by Semantic Web-aware applications. Over time, however, implementers are encouraged to use the semantically more precise dcterms: properties, as they more fully follow emerging notions of best practice for machine-processable metadata.

The intent behind labelling them as "legacy" is, as Tom Baker puts it, to "gently promote" the use of the more recently defined set of properties.

Perhaps the most significant characteristic of that set of terms is that it was created as a "functional" set, by which I mean that it was created with the notion that that set of fifteen properties could and would be used together in combination in the descriptions of resources. And I think this is reflected, for instance, in the fact that some of the "comments" provided for individual properties refer to other properties in that set (e.g. dc:subject/dc:coverage, dc:format/dc:type).

And there was particular emphasis placed on one "pattern" for the construction of descriptions using those fifteen properties, in which a description could contain statements referring only to those fifteen properties, all used with literal values, and any of those 15 properties could be referred to in multiple statements (or in none). In that pattern of usage, the fifteen properties were all "optional and repeatable", if you like. And that pattern is often referred to as "Simple Dublin Core".

Such a "pattern" is what today - if viewed from the perspective of the DCMI Abstract Model and the Singapore Framework - we would call a Description Set Profile (DSP).

So "Simple Dublin Core" might be conceptualised as a DSP designed, initially at least, for use within a very simple, general purpose DC Application Profile (DCAP), constructed to support some functions related to the discovery of a broad range of resources. That DSP specifies the following constraints:

  • 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 property URI must be drawn from a list of the fifteeen URIs of the DCMES properties (Statement Template: Property list constraint: (the 15 URIs))
    • There must be at least one such statement; there may be many (Statement Template: Minimum occurrence constraint = 1; 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)

And this DSP represents a "pattern" that is quite widely deployed, perhaps most notably in the context of systems supporting the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH), which requires that an OAI-PMH repository expose records using an XML format called oai_dc, which is essentially a serialisation format for this DSP. (There may be an argument that the "Simple DC" pattern has been overemphasised at the expense of other patterns, and as a result people have poured their effort into using that pattern when a different one might have been more appropriate for the task at hand, but that's a separate discussion!)

It seems to me that, historically, the association between the DCMES as a set of terms on the one hand and that particular pattern of usage of those terms on the other was so close that, at least in informal accounts, the distinction between the two was barely made at all. People tended to (and still do) use the terms "Dublin Core Metadata Element Set" and "Simple Dublin Core" interchangeably. So, for example, in the introduction to the Usage Guide, one finds comments like "Simple Dublin Core comprises fifteen elements" and "The Dublin Core basic element set is outlined in Section 4. Each element is optional and may be repeated." I'd go as far as to say that many uses of the generic term "Dublin Core", informal ones at least, are actually references to this one particular pattern of usage. (I think the glossary of the Usage Guide does try to establish the difference, referring to "Simple Dublin Core" as "The fifteen Dublin Core elements used without qualifiers, that is without element refinement or encoding schemes.")

The failure to distinguish more clearly between a set of terms and one particular pattern of usage of those terms has caused a good deal of confusion, and I think this will becomes more apparent when we consider the (rather more complex) case of "Qualified Dublin Core", as I'll do in the next post, and it's an area which I'm hoping will be addressed as part of the Usage Board review of documentation.

If you look at the definitions of the DCMES properties, in the human-readable document, and especially in the RDF Schema descriptions provided in the "namespace document" http://purl.org/dc/elements/1.1/, with the possible exceptions of the "cross-references" I mentioned above, those definitions don't formally say anything about using those terms together as a set, or about "optionality/repeatability": they just define the terms; they are silent about any particular "pattern of usage" of those terms.

So, such patterns of usage of a collection of terms exist distinct from the collection of terms. And it is possible to define multiple patterns of usage. multiple DSPs, referring to that same set of 15 properties. In addition to the "all optional/repeatable" pattern, I might find myself dealing with some set of resources which all have identifiers and all have names, and operations on those identifiers and names are important to my application, so I could define a pattern/DSP ("PeteJ's Basic DC" DSP) where I say all my descriptions must contain at least one statement referring to the dc:identifier property and at least one statement referring to the dc:title property, and the other thirteen properties are optional/repeatable, still all with literal values. Another implementer might find themselves dealing with some stuff where everything has a topic drawn from some specified SKOS concept scheme, so they define a pattern ("Fred's Easy DC" DSP) which says all their descriptions must contain at least one statement referring to the dc:subject property and they require the use, not of a literal, but of a value URI from that specific set of URIs. So now we have three three different DC Application Profiles, incorporating three different patterns for constructing description sets (three different DSPs) each referring to the same set of 15 properties.

It's also worth noting that the "Simple DC" pattern of usage, a single set of structural constraints, could be deployed in multiple DC Application Profiles, supporting different applications and containing different human-readable guidelines. (I was going to point to the document Using simple Dublin Core to describe eprints as an actual example of this, but having read that document again, I think strictly speaking it probably introduces additional structural constraints (i.e. introduces a different DSP), e.g. it requires that statements using the dc:type property refer to values drawn from a bounded set of literal values.)

The graphic below is an attempt to represent what I see as those relationships between the DCMES vocabulary, DSPs and DCAPs:

Slide1

Finally, it's worth emphasising that the 15 properties of the DCMES, or indeed any subset of them - there is no requirement that a DSP refer to all, or indeed any, of the properties of the DCMES - , may be referred to in other DSPs in combination with other terms from other vocabularies, owned either by DCMI or by other parties.

Slide2

The point that DCMI's concept of an "application profile" is not based either on the use of the DCMES properties in particular or on the "Simple DC" pattern is an important one. Designing a DC application profile does not require taking either the DCMES or the "Simple DC" pattern as a starting point; any set of properties, classes, vocabulary encoding schemes and syntax encoding schemes, owned by any agency, can be referenced. But that is rather leading me into the next post, where I'll consider the similar (but rather more messy) picture that emerges once we start talking about "Qualified DC".

October 06, 2009

FOTE09

FOTE (the Future of Technology in Education conference organised by ULCC), which I attended on Friday, is a funny beast.  For two years running it has been a rather mixed conference overall but one that has been rescued by one or two outstanding talks that have made turning up well worthwhile and left delegates going into the post-conference drinks reception with something of a buzz.

Last year it was Miles Metcalfe of Ravensbourne College who provided the highlight.  This year it was down to Will McInnes (of Nixon/McInnes) to do the same, kicking off the afternoon with a great talk, making up for a rather ordinary morning, followed closely by James Clay (of Gloucestershire College).  If this seems a little harsh... don't get me wrong.  I thought that much of the afternoon session was worth listening to and, overall, I think that any conference that can get even one outstanding talk from a speaker is doing pretty well - this year we had at least two.  So I remain a happy punter and would definitely consider going back to FOTE in future years.

My live-blogged notes are now available in a mildly tidied up form.  This year's FOTE was heavily tweeted (the wifi network provided by the conference venue was very good) and about half-way thru the day I began to wonder if my live-blogging was adding anything to the overall stream?  On balance, and looking back at it now, I think the consistency added by by single-person viewpoint is helpful.  As I've noted before, I live-blog primarily as a way of taking notes.  The fact that I choose to take my notes in public is an added bonus (hopefully!) for anyone that wants to watch my inadequate fumblings.

The conference was split into two halves - the morning session looking at Cloud Computing and the afternoon looking at Social Media.  The day was kicked off by Paul Miller (of Cloud of Data) who gave a pretty reasonable summary of the generic issues but who fell foul, not just of trying to engage in a bit of audience participation very early in the day, but of trying to characterise issues that everyone already understood to be fuzzy and grey into shows of hands that required black and white, yes/no answers.  Nobody fell for it I'm afraid.

And that set the scene for much of the morning session.  Not enough focus on what cloud computing means for education specifically (though to his credit Ray Flamming (of Microsoft) did at least try to think some of that through and the report by Robert Moores (of Leeds Met) about their experiences with Google Apps was pretty interesting) and not enough acknowledgment of the middle ground.  Even the final panel session (for which there was nowhere near enough time by the way) tried to position panelists as either for or against but it rapidly became clear there was no such divide.  The biggest point of contention seemed to be between those who wanted to "just do it" and those who wanted to do it with greater reference to legal and/or infrastructural considerations - a question largely of pace rather than substance.

If the day had ended at lunchtime I would have gone home feeling rather let down.  But the afternoon recovered well.  My personal highlights were Will McInnes, James Clay and Dougald Hine (of School of Everything), all of whom challenged us to think about where education is going.  Having said that, I think that all of the afternoon speakers were pretty good and would likely have appealed to different sections of the audience, but those are the three that I'd probably go back and re-watch first. All the video streams are available from the conference website but here is Will's talk:

One point of criticism was that the conference time-keeping wasn't very good, leaving the final two speakers, Shirley Williams (of the University of Reading, talking about the This is Me project that we funded) and Lindsay Jordan (of the University of Bath/University of the Arts) with what felt like less than their alloted time.

For similar reasons, the final panel session on virtual worlds also felt very rushed.  I'd previously been rather negative about this panel (what, me?), suggesting that it might descend into pantomime.  Well, actually I was wrong.  I don't think it did (though I still feel a little bemused as to why it was on the agenda at all).  Its major problem was that there was only time to talk about one topic - simulation in virtual worlds - which left a whole range of other issues largely untouched.  Shame.

Overall then, a pretty good day I think.  Well done to the organisers... I know from my own experience with our symposium that getting this kind of day right isn't an easy thing to do.  I'll leave you with a quote (well, as best as I can remember it) from Lindsay Jordan who closed her talk with a slightly sideways take on Darwinism:

in the social media world the ones who survive - the fittest - are the ones who give the most

October 05, 2009

QNames, URIs and datatypes

I posted a version of this on the dc-date Jiscmail list recently, but I thought it was worth a quick posting here too, as I think it's a slightly confusing area and the differences in naming systems is something which I think has tripped up some DC implementers in the past.

The Library of Congress has developed a (very useful looking) XML schema datatype for dates, called the Extended Date Time Format (EDTF). It appears to address several of the issues which were discussed some time ago by the DCMI Date working group. It looks like the primary area of interest for the LoC is the use of the data type in XML and XML Schema, and the documentation for the new datatype illustrates its usage in this context.

However, as far as I can see, it doesn't provide a URI for the datatype, which is a prerequisite for referencing it in RDF. I think sometimes we assume that providing what the XML Namespaces spec calls an expanded name is sufficient, and/or that doing that automatically also provides a URI, but I'm not sure that is the case.

In XML Schema, a datatype is typically referred to using an XML Qualified Name (QName), which is essentially a "shorthand" for an "expanded name". An expanded name has two parts: a (possibly null-valued) "namespace name" and a "local name".

Take the case of the built-in datatypes defined as part of the XML Schema specification. In XML/XML Schema, these datatypes are referenced using these two part "expanded names", typically represented in XML documents as QNames e.g.

<count xsi:type="xsd:int">42</count>

where the prefix xsd is bound to the XML namespace name "http://www.w3.org/2001/XMLSchema". So the two-part expanded name of the XML Schema integer datatype is

( http://www.w3.org/2001/XMLSchema , int )

Note: no trailing "#" on that namespace name.

The key point here is that the expanded name system is a different naming system from the URI system. True, the namespace name component of the expanded name is a URI (if it isn't null), but the expanded name as a whole is not. And furthermore, there is no generalised mapping from expanded name to URI.

To refer to a datatype in RDF, I need a URI, and for the built-in datatypes provided, the XML Schema Datayping spec tells me explicitly how to construct such a URI:

Each built-in datatype in this specification (both *primitive* and *derived*) can be uniquely addressed via a URI Reference constructed as follows:

  1. the base URI is the URI of the XML Schema namespace
  2. the fragment identifier is the name of the datatype

For example, to address the int datatype, the URI is:

* http://www.w3.org/2001/XMLSchema#int

The spec tells me that for the names of this set of datatypes, to generate a URI from the expanded name, I use the local part as the fragment id - but some other mechanism might have been applied.

And this is different from, say, the way RDF/XML maps the QNames of some XML elements to URIs, where the mechanism is simple concatenation of "namespace name" and "local name"

(And, as an aside, I think this makes for a bit of "gotcha" for XML folk coming to RDF syntaxes like Turtle where datatype URIs can be represented as prefixed names, because the "namespace URI" you use in Turtle, where the simple concatenation mechanism is used, needs to include the trailing "#" (http://www.w3.org/2001/XMLSchema#), whereas in XML/XML Schema people are accustomed to using the "hash-less" XML namespace name (http://www.w3.org/2001/XMLSchema)).

But my understanding is that that the mapping defined by the XML Schema datatyping document is specific to the datatypes defined by that document ("Each built-in datatype in this specification... can be uniquely addressed..." (my emphasis)), and the spec is silent on URIs for other user-defined XML Schema datatypes.

So it seems to me that if a community defines a datatype, and they want to make it available for use in both XML/XML Schema and in RDF, they need to provide both an expanded name and a URI for the datatype.

The LoC documentation for the datatype has plenty of XML examples so I can deduce what the expanded name is:

(info:lc/xmlns/edtf-v1 , edt)

But that doesn't tell me what URI I should use to refer to the datatype.

I could make a guess that I should follow the same mapping convention as that provided for the XML Schema built-in datatypes, and decide that the URI to use is

info:lc/xmlns/edtf-v1#edt

But given that there is no global expanded name-URI mapping, and the XML Schema specs provide a mapping only for the names of the built-in types, I think I'd be on shaky ground if I did that, and really the owners of the datatype need to tell me explicitly what URI to use - as the XML Schema spec does for those built-in types.

Douglas Campbell responded to my message pointing to a W3C TAG finding which provides this advice:

If it would be valuable to directly address specific terms in a namespace, namespace owners SHOULD provide identifiers for them.

Ray Denenberg has responded with a number of suggestions: I'm less concerned about the exact form of the URI than that a URI is explicitly provided.

P.S. I didn't comment on the list on the choice of URI scheme, but of course I agree with Andy's suggestion that value would be gained from the use of the http URI scheme.... :-)

SharePoint in UK universities - literature review

We are currently funding the University of Northumbria to undertake some work for us looking at the uptake of Microsoft SharePoint in UK universities.  As part of this work we have just published a literature review [PDF] by James Lappin and Julie McLeod:

SharePoint 2007 has spread rapidly in the Higher Education (HE) sector, as in most other market sectors. It is an extra-ordinarily wide ranging piece of software and it has been put to a wide variety of different uses by different UK Higher Education Institutions (HEIs). This literature review is based upon what HEIs have been willing to say about their implementations in public.

Implementations range from the provision of team sites supporting team collaboration, through the use of SharePoint to support specific functions, to its use as an institutional portal, providing staff and/or students with a single site from which to access key information sources and tools.

By far the most common usage of SharePoint in UK HEIs is for team collaboration. This sees SharePoint team sites replacing, or supplementing, network shared drives as the area in which staff collaborate on documents and share information with each other.

About

Search

Loading
eFoundations is powered by TypePad