When your OpenID provider goes offline…

 My main OpenID provider is currently LiveJournal, delegated from my own danbri.org domain. I suspect it’s much more likely that danbri.org would go offline or be hacked again (sorry DreamHost) than LJ; but either could happen!

In such circumstances, what should a ‘relying party’ (aka consumer) site do? Apparently myopenid has been down today; these are not theoretical scenarios. And my danbri.org site was hacked last year, due to a DreamHost vulnerability. The bad guys merely added viagra adverts; they could easily have messed with my OpenID delegation URL instead.

I don’t know the OpenID 2.0 spec inside-out (to put it mildly!) but one model that strikes me as plausible: the relying party should hang onto FOAF and XFN ‘rel=me’ data that you’ve somehow confirmed (eg. those from http://danbri.org/foaf.rdf or my LJ FOAF) and simply offer to let you log in with another OpenID known to be associated with you. You might not even know in advance that these other accounts of yours offer OpenID; after all there are new services being rolled out on a regular basis. For a confirmed list of ‘my’ URLs, you can poke around to see which are OpenIDs.

danbri$ curl -s http://danbri.livejournal.com/ | grep openid
<link rel=”openid.server” href=”http://www.livejournal.com/openid/server.bml” />

danbri$ curl -s http://flickr.com/photos/danbri/ | grep openid
<link rel=”openid2.provider” href=”https://open.login.yahooapis.com/openid/op/auth” />

Sites do go down. It would be good to have a slicker user experience when this happens. Given that we have formats – FOAF and XFN at least – that allow a user to be associated with multiple (possibly OpenID-capable) URLs, what would it take to have OpenID login make use of this?

MusicBrainz SQL-to-RDF D2RQ mapping from Yves Raimond

More great music-related stuff from Yves Raimond. He’s just announced (on the Music ontology list) a D2RQ mapping of the MusicBrainz SQL into RDF and SPARQL. There’s a running instance of it on his site. The N3 mapping files are on the  motools sourceforge site.

Yves writes…

Added to the things that are available within the Zitgist mapping:

  •  SPARQL end point
  •  Support for tags
  • Supports a couple of advanced relationships (still working my way  through it, though)
  • Instrument taxonomy directly generated from the db, and related to performance events
  • Support for orchestras

This is pretty cool, since the original MusicBrainz RDF is rather dated (if it’s even still available). The new representations are much richer and probably also easier to maintain.

Nearby in the Web: discussion of RDF views into MySpace; and the RDB2RDF Incubator Group at W3C discussions are getting started (this group is looking at technology such as D2RQ which map non-RDF databases into our strange parallel world…)

IRC RDF logs and foaf:chatEvent

For many years, the 24×7 IRC chatrooms #swig and #foaf (and previously #rdfig) have been logged to HTML and RDF by Dave Beckett‘s IRC logging code. The RDF idiom used here dates from 2001 or so, and looks like this:

 <foaf:ChatChannel rdf:about=”irc://irc.freenode.net/swig”>
<foaf:chatEventList>
<rdf:Seq>
<rdf:li>
<foaf:chatEvent rdf:ID=”T00-05-11″>
<dc:date>2008-04-03T00:05:11Z</dc:date>

<dc:description>
danbri: do you know of good scutter data for playing with codepiction? would be fun to get back into that (esp. parallelization).
</dc:description>
<dc:creator>
<wn:Person foaf:nick=”kasei”/>
</dc:creator>
</foaf:chatEvent>

Dave has offered to make a one-time search-and-replace fix to the old logs, if we want to agree a new idiom. The main driver for this is that the old logs have a class for ‘chat event’  but use an initial lowercase later for the term, ie. ‘chatEvent’ instead of ‘ChatEvent’. None of these properties are yet documented in the FOAF schema, and since the data for this term is highly concentrated, and its maintainer has offered to change it, I suggest we document these FOAF terms as used, with the fix of having a class foaf:ChatEvent instead of foaf:chatEvent.

Almost all  RDF vocabularies stick to the rule of using initial lowercase letters for properties, and initial capitals for classes. This makes RDF easy to read for those who know this trick; consequently a lowercase class name can be very confusing, for experts and beginners alike. I’d therefore rather not introduce one into FOAF if it can be avoided. But I would like to document the IRC logging data format, and continue to use FOAF for it.

The markup also uses the wordnet:Person class from my old Wordnet 1.6 namespace (currently offline, but will be repaired eventually, albeit with a later Wordnet installation). This follows early FOAF practice, where we minimised terms and used Wordnet a lot more. I suggest Dave updates this to use foaf:Person instead. The dc:creator property used here might also use the new DC Terms notion of ‘creator’, since that flavour of ‘creator’ has a range of DC Terms “Agent” that is a more modern and FOAF-compatible idiom. This btw is a candidate for using instead of foaf:maker, which I introduced with some regret only because the old dc:creator property had such weak usage rules. But then if we change the DC namespace used for ‘creator’ here, should we change the other ones too? Hmm hmm hmm etc.

The main known consumer of this IRC log data is XSLT created and maintained by the ubiquitous Dave. If you know of other downstream consumer apps please let us know by commenting in the blog or by email.

While there are other ways in which such chatlogs might be represented in RDF (eg. SIOC, or using something linked to XMPP), let’s keep the scope of this change quite small. The goal is to make a minimal fix to the current archived instance data  and associated tools, so that the FOAF vocabulary it uses can be documented.

Comments welcomed…

One Big Happy Family (FOAF/RDF and Microformats)

I just signed up to give a talk at the Microformats vEvent in London, May 27th; thanks to the organizers (Frances Berriman and Drew McLellen of microformats.org) for inviting me :)

I’ve called it “One Big Happy Family: Practical Collaboration on Meaningful Markup” and my goal really is to help make it easier for enthusiasts for both RDF and Microformats to say ‘we‘ rather than ‘they‘ a bit more often when discussing complementary efforts from this community. As I said on the foaf-dev list yesterday, “anything good for Microformats is good for FOAF”; vice-versa too, I hope. There’s only one Web and we’re all doing our bit, with the tools and techniques we know best.

Here’s the abstract:

This talk explores some ways in which the Microformat and RDF approaches can complement each other, and some ways in which we can share data, tools and experiences between these two technologies. It will outline the often-unarticulated history of the RDF design, the techniques used for parsing and querying RDF data, and the things made easy and hard through this approach. RDF techniques can be contrasted with the different choices made for Microformats. However these differences obscure an underlying similarity that comes from shared ‘Webby’ values.

Edit: it seems I’m incapable of spelling “compl[ie]mentary”. Freudian slip? :)

BTW the London Web Week site has just gone live; check it out…