[foaf-dev] foaf:OnlineAccount owl:disjointWith foaf:Document ? [was strawpoll: migrate from foaf:holdsAccount to foaf:account?]

Peter Williams pwilliams at rapattoni.com
Tue Aug 25 15:44:00 CEST 2009


"Similarly,

        <#cygri> foaf:account <http://twitter.com/cygri> .

is a perfectly consistent way of modelling account ownership,"


This goes back to my original point. Who owns a document (and an account) may have little to do with the person denoted by #cygri. Typically, if you stop being a subscriber of facebook (because THEY SAY you broke some rule), you suddenly lose ownerhip of what you never owned in the first place (because they own it, in copyright sense). The same goes with "your" FOAF document from sixapart's portal - which "you" probably don’t own either.

This is the crunch point for most identity url systems, distinguishing the resources (the youtube channel of #danbri) from the identity - which has lifecycle all of its own, since its referenced sometimes on the assumptions that its persistent (when its not).

Since facebook can be reasonably expected to shortly be making openid assertions about the accounts identifier that you DO NOT own (because they do), it's true that you "_have_ an account" at facebook. It's probably not true that you own it, tho (even tho 99% of folks probably "think" (falsely) they have certain entitlements.)

This is all rather important for foaf+ssl, as the #danbri name will itself become the asserted identity via the client cert-based uri. In foaf+ssl, the relying party doing access control using the metadata about #danbri from the foaf file (e.g. ownership statements about other accounts, or groups) may be misled. For all we know, tomorrow facebook will take their ownership rights and give the account name/url for danbri to peter, in some auction of hot urls.

-----Original Message-----
From: foaf-dev-bounces at lists.foaf-project.org [mailto:foaf-dev-bounces at lists.foaf-project.org] On Behalf Of Toby Inkster
Sent: Tuesday, August 25, 2009 4:44 AM
To: foaf-protocols at lists.foaf-project.org; foaf-dev at lists.foaf-project.org
Subject: [foaf-dev] foaf:OnlineAccount owl:disjointWith foaf:Document ? [was strawpoll: migrate from foaf:holdsAccount to foaf:account?]

Let us examine this in the context of another relationship:

        # Bob is Alice's brother.
        <http://alice.example.com/> a foaf:Document ;
                xfn:sibling <http://bob.example.com/> .
        <http://bob.example.com/> a foaf:Document .

This document-to-document relationship (used in XFN) jars with a lot of
people. However, it is a perfectly valid way of modelling the
relationship between Alice and Bob, provided it is used consistently:
provided that the xfn:sibling term is specifically defined as linking
from document to document, such that the "owners" (whatever that means)
of the documents are siblings; provided it's never used with, say, a
foaf:Person as the domain or range.

Similarly,

        <#cygri> foaf:account <http://twitter.com/cygri> .

is a perfectly consistent way of modelling account ownership, provided
that we're clear that foaf:account is defined as linking not from a
person to (the rather abstract idea of) an account, but as linking from
a person to a document associated with that account. (We can even call
that document a foaf:OnlineAccount, provided again that we are
consistent with that definition.)

That definition is consistent and usable, however we have to ask whether
it's a better way of modelling accounts than the alternative, which
would be:

        <#cygri> foaf:account [
                foaf:accountProfilePage <http://twitter.com/cygri>
                ] .

The former is clearly more concise, and thus presumably "easier" for
people to use. The latter has the advantage that separate data can be
provided for the account and the page. Ian's example of the creation
date for the account and page being different may be contrived, but it's
still conceivable that such a thing could happen. e.g. an existing
instant messaging service could at some point start providing profile
pages for its users - the document creation date and the account
creation date would then differ.

Perhaps a solution might be that we keep foaf:holdsAccount and introduce
a foaf:account property too...

        foaf:holdsAccount
                rdfs:domain foaf:Agent ;
                rdfs:range foaf:OnlineAccount .
        foaf:account
                rdfs:domain foaf:Agent;
                rdfs:range foaf:AccountProfileDocument ;
                rdfs:subPropertyOf foaf:page .
        foaf:AccountProfileDocument
                owl:disjointWith foaf:OnlineAccount ;
                rdfs:subClassOf foaf:Document .
        foaf:accountProfilePage
                rdfs:domain foaf:OnlineAccount ;
                rdfs:range foaf:AccountProfileDocument ;
                rdfs:subPropertyOf rdfs:seeAlso .

We could then add some OWL2 rules to tell us that this:

        ?person foaf:holdsAccount [ foaf:accountProfilePage ?page ] .

implies this:

        ?person foaf:account ?page .

In this diagramme I drew some time ago:

http://buzzword.org.uk/2009/foaf-Person-OnlineAccount-Document.png

The arc labelled "???" would be accountProfilePage and the label
"homepage" would become "account". (Ignore the bidirectionality of the
arrow heads -- I don't know why I did that.)

--
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>

_______________________________________________
foaf-dev mailing list
foaf-dev at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-dev


More information about the foaf-dev mailing list