Authorization by Codepiction

Over the last fours years and counting, I have been providing access to a triplestore with description of my photos through a facetted interface. Through those years I have received several requests for excluding people from the searchable interface, as they showed up quite prominently on Google.

It turned out to make the interface much less useful for me — and possibly for others as well — so not too long ago I ended up simply excluding photos depicting people — using SPARQL, of course:

PREFIX foaf: <>
SELECT ?Photo 
WHERE { ?Photo foaf:depicts ?Person .
        ?Person a foaf:Person }

That, of course, didn’t really improve things from my personal perspective, so watching others experiment with OpenID and social networking, I decided to take the same route — with a twist.

I didn’t really want to maintain or discover a social network for this use, but then it dawned on me: My photos actually represent a social network, as codepiction describes relations between people even better than explicitly stated ones.

With that in mind, I got the most recent version of the PHP OpenID Library up and running, and now use SPARQL to extend the non-person subset created above with photos of codepictees for users logged in with their OpenID — assuming they match with the descriptions in the store:

PREFIX foaf: <>
SELECT ?Photo 
WHERE { ?Photo foaf:depicts ?Friend .
        ?OtherPhoto foaf:depicts ?Friend .
        ?OtherPhoto foaf:depicts ?User .
        ?User ?ifp ?OpenID .
        ?ifp a owl:InverseFunctionalProperty }

Note that since I don’t restrict ?User to be distinct from ?Friend (and ?Photo from ?OtherPhoto), the query also returns photos depicting the user. The query also doesn’t explicitly look for foaf:openid, but rather any inverse functional property, and since I’ve used foaf:mbox/foaf:mbox_sha1sum quite a lot in the descriptions of the photos’ depictees, I have added the option to verify your e-mail address — it is not enough to trust what’s returned from an OpenID provider, as there is no validation, and I wouldn’t want everyone to create OpenID identities with my e-mail address.

All in all, you can now use OpenID to log into my facetted interface and — if you are recognized — get access to additional photos. Try it!

Quite slick use of codepiction, if I may say so myself…

NB: I cheated. Parts of the backend still use an old RDQL engine, so some of this was actually not done in SPARQL. Also, I supplemented the above codepiction query with queries regarding albums with codepiction and photographer information (mostly useful for myself, of course), meaning you will actually see more photos than you might expect.

12 thoughts on “Authorization by Codepiction

  1. Excellent work! I think I might try to replace my TypeKey-based implementation (that has become somewhat bitrotten) with an OpenID approach like yours. Certainly seems like the proper way forward, and I could do without the constant emails requesting images be taken down :)

    Also, I think I need to verify my email address, but can’t sort out where that’s done. Pointers?

  2. Ah. Good one.

    I didn’t test it with an OpenID provider that didn’t provide an e-mail address using SREG — I use MyOpenID, that gives me the choice for each transaction, and I didn’t try not passing it on.

    Once it is passed on, you will be presented with an extra button, “Send verification e-mail”.

    For now, I have updated the message a bit, so that it hopefully explains that the e-mail address needs to come from the identity provider.

    I’ll think about adding an option for entering an e-mail address…

  3. Cool hack! Not sure what is missing to teach it that I’m me…

    “””You are logged in as
    You are logged in with your OpenID, but apparently it is not known to the database, so it doesn’t give you access to additional photos.
    If your OpenID information included your e-mail address, you could verify it, and then perhaps be able to see up to 3797 more photos!”””

    What does it mean for my OpenID info to include my email address? you’re using attribute exchange?

    ps. will you use openid for blog comments too?

  4. @Dan: Yes and yes. :)

    With regards to OpenID for comments, yes, that’s also in the pipeline, although I need to upgrade to a modern version of WordPress first, and I’m not quite sure how/if to integrate with the codepiction data. Perhaps a simple export of my codepictees will do…

  5. Nicely done Morten.
    How do I make my OpenId known to your database?
    I managed to verify my email instead, but it’d be nice to test it just with OpenId.

  6. @Jesper: I’m (currently) the only one that can add triples to the database, but as of now I subscribe to a feed with OpenID-users, so I will update my address book with new information that comes along. Give it a try again tomorrow (or try with your blog URL instead, if you can make it delegate)…

  7. What feed is that?

    My openid uri has a meta link pointing to my foaf file.
    My foaf file references my openid uri and my verified email and is signed by me using gpg. In a perfect world that should be enough for you to deduce all the needed knowledge.
    Maybe something to consider for version 2.0 :)

  8. Jesper,

    I think there’s at least one flaw in the chain of trust you’re proposing:

    Imagine me putting up a FOAF file, pointing to it from my OpenID (, and adding the following statements:
    _:me foaf:openid <> .
    _:me foaf:homepage <> .
    _:me foaf:mbox << > .

    Then, I create a new GPG key with as the ID, and sign the FOAF file.

    Following your proposal I would be able to gain access to the photos of the person identified by or

    Surely, I can’t really trust anything but the foaf:openid statement?

Comments are closed.