Slurls are great... they provide a fantastic way of integrating SL resources into the fabric of the Web (and in particular into Web 2.0 services). For example, by using a Slurl I can bookmark a resource in SL using del.icio.us - in fact, I can use a Slurl any place that I can currently use a URL.
However... and this is a pretty big however... Slurls suffer from exactly the same kind of persistence problems as URLs. Probably worse in fact, because a Slurl, by definition, really does identify a 'location' whereas a URL can (and often does) act purely as an identifier. If a resource gets moved to a new location in SL, its Slurl stops working as a useful link.
Take for example the Slurl for ArtsPlace SL that I've used in previous postings to this blog:
http://slurl.com/secondlife/pak/113/24/117/
ArtsPlace has now moved from Pak to Eduserv Island. Going to the above Slurl now will land you bang splat in the middle of some kind of bondage cave - at least it did the last time I tried it. What you get to depends on what is currently at that location. There is no easy way of persistently linking to a resource like ArtsPlace in SL (as opposed to a particular location of the resource).
This problem can be solved by adding a level of indirection. (As everyone knows, all computer science problems can be solved by adding one level of indirection! :-) ).
A Splurlis a SL PURL (yes, I know that the acronym isn't perfect!). A PURL is a persistent URL, so a Splurl is a persistent Slurl. Splurls work by using the PURL system to maintain a mapping from each Splurl to the current Slurl for the resource in question. When the Splurl is used as the basis for a hypertext link, the PURL server issues an HTTP redirect to the current Slurl.
Here's one for ArtsPlace SL:
http://purl.org/net/splurl/artsplacesl
Easy huh?? The Splurl will work as a useful identifier and link for ArtsPlace SL for as long as the PURL system continues to work, irrespective of where ArtsPlace happens to be located. If for some reason I have to move ArtsPlace in the future, then all I'll have to do is update the PURL mapping table to the new Slurl.
skip to main |
skip to sidebar
Blog Archive
-
▼
2007
(174)
-
▼
April
(17)
- Suffern Middle School in Second Life
- Second Cite - a PURL-based persistent citation for...
- Sculptured prims
- SJSU SLIS machinima
- Holodeck teaching/meeting space on Eduserv Island
- Oxford Uni in SL
- An English Village
- Camera controls
- Splurls anyone?
- Eduserv Island
- SLashup
- ArtsPlace SL has moved
- On naming...
- Meanwhile in Manchester...
- Presentation to Eduserv staff
- Eduserv Island
- Museums and the Web paper
-
▼
April
(17)
4 comments:
Cool! I guess the "p" in "Splurl" is in the wrong place really, but I agree "Splurl" is (slightly!) less of a mouthful than "Slpurl" ;-)
An interesting question here, which you touch on in your post, is whether the two URIs (the Splurl itself and the Slurl to which it is redirected) identify the same type of thing. As you say, the Slurl identifies a specific SL Location, a place in SL. That seems clear. Fine.
In terms of what the Splurl identifies, I guess I could see two approaches:
(a) the Splurl identifies the current SL Location of ArtsPlace (i.e. the resource by the Splurl identified is still an SL Location);
(b) the Splurl identifies some other resource in SL (ArtsPlace as an object or set of objects? Or even ArtsPlace as an "institution"/"agent"?) i.e. the resource identified by the Splurl is something other than an SL Location.
In terms of the redirect behaviour of the PURL server, I think either approach could be justified as consistent with the Web Architecture (though I guess strictly speaking, if the Splurl identifies a non-information resource, then following the W3C TAG httpRange-14 resolution, the redirect should use a 303 status code).
But when you come to make assertions about the resource in RDF - which I'm sure you will be doing! ;-) - then it becomes important to be clear what the identified resource is, and to be consistent in the use of the URI e.g. if the Splurl identifies an Agent then the Splurl could be used as the value in a statement using the dcterms:publisher property. If it identifies an SL Location, then I think such a use with dcterms:publisher would be potentially contradictory, because Locations aren't Agents (IMHO).
Blimey... Second Life and RDF in the same comment - whatever next?!
What's next? Ajax and avatars? Second Life on Rails? ;-)
An interesting scenario and something I had not even thought of as an issue. SLURLS seem kludgy to me; last checked they do not work in IE7 (no surprise) and even in Firefox the last few weeks, there is no map.
So what it seems what is desired is some sort of universal ID for locations? If Second Life themselves built this in to the architecture, then web sl urls could be generated based on the ID, not the current physical location.
But please, a tastier acronym!
Alan,
yes, I agree about the 'tastier acronym'. Assuming that we stick with PURLs as the solution, then one possibility is just to call them 'SL PURLs' or 'Second Life PURLs' - i.e. there is no acronym as such, the name is purely descriptive!
Post a Comment