tag:blogger.com,1999:blog-812407467138247259.post8921050006050037129..comments2023-06-15T21:09:36.504-07:00Comments on ArtsPlace SL: Splurls anyone?Art Fossetthttp://www.blogger.com/profile/06036853556502498237noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-812407467138247259.post-20600936524904221302007-04-29T00:44:00.000-07:002007-04-29T00:44:00.000-07:00Alan,yes, I agree about the 'tastier acronym'. As...Alan,<BR/>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!Andy Powellhttps://www.blogger.com/profile/08976669204636256165noreply@blogger.comtag:blogger.com,1999:blog-812407467138247259.post-47870266252442971202007-04-20T07:13:00.000-07:002007-04-20T07:13:00.000-07:00What's next? Ajax and avatars? Second Life on Rail...What's next? Ajax and avatars? Second Life on Rails? ;-)<BR/><BR/>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. <BR/><BR/>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. <BR/><BR/>But please, a tastier acronym!Alanhttps://www.blogger.com/profile/02980801837743251948noreply@blogger.comtag:blogger.com,1999:blog-812407467138247259.post-29156643079437636042007-04-19T03:14:00.000-07:002007-04-19T03:14:00.000-07:00Blimey... Second Life and RDF in the same comment ...Blimey... Second Life and RDF in the same comment - whatever next?!Andy Powellhttps://www.blogger.com/profile/08976669204636256165noreply@blogger.comtag:blogger.com,1999:blog-812407467138247259.post-56714817805052359752007-04-18T03:23:00.000-07:002007-04-18T03:23:00.000-07:00Cool! I guess the "p" in "Splurl" is in the wrong ...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" ;-)<BR/><BR/>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. <BR/><BR/>In terms of what the Splurl identifies, I guess I could see two approaches:<BR/><BR/>(a) the Splurl identifies the current SL Location of ArtsPlace (i.e. the resource by the Splurl identified is still an SL Location);<BR/><BR/>(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.<BR/><BR/>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).<BR/><BR/>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).PeteJhttps://www.blogger.com/profile/10254946435103734509noreply@blogger.com