[foaf-dev] [foaf-protocols] revisiting FOAF project goals

Peter Williams pwilliams at rapattoni.com
Wed Jun 24 18:33:03 CEST 2009


http://graceland.parityinc.net/xdi-signer/XDISigner for graph signing in a world involving persistent cids.

if I have a reference to a friend's WebID like

http://xri.rapattoni.com/(http://homepw.org/foaf.rdf#me)*marcus

the url might be criticized for its technicalities and philisophy : the foaf file mau not be public, and its debatable whether in foafland it is appropirateness to use a resolver agent (xri.rapattoni.com) to get fine-grained access rights).

But, that never-ending debate about URLs aside, its supposed to mean that one naming and trust enviornment (peter's foaf file) provides a local context that can resolve the name marcus (or drummond, say). Before http://xri.rapattoni.com redirects me somewhere temporarily or permanently - consistent with HTTP semantics - this agent might verify the trust graph represented in a users trust statements (in XRI space) vs the friends-mesh expressed in the foaf file.

Being aimed at machine processing, we have to remember that there will probably have to be 2 trust ovlerays - one that assists in creating associations between computer agents, and one that assists in creating authorizations, obligations and assertions between users.This distinction is similar to that between the address of a foaf file url, vs identity of a WebID.

Ideally, a common trust resolution infrastructure would serve both addressing and identity, and allow a more intelligent machine client to use any foaf file as a naming context - and have assurance that URIs in foaf files are cids.

Now, we do already types for PGP signed rdf graphs (as seen in the foaf ontology/spec). But it seems ancient - and limited to public key crypto.


________________________________________
From: foaf-dev-bounces at lists.foaf-project.org [foaf-dev-bounces at lists.foaf-project.org] On Behalf Of Kingsley Idehen [kidehen at openlinksw.com]
Sent: Wednesday, June 24, 2009 8:28 AM
To: Dan Brickley
Cc: foaf-protocols at lists.foaf-project.org; Matthew Rowe; foaf-dev Friend of a
Subject: Re: [foaf-dev] [foaf-protocols]  revisiting FOAF project goals

Dan Brickley wrote:
> On 24/6/09 13:33, Matthew Rowe wrote:
>
>> Hello
>>
>> I concur with what Dave has said here, particularly regarding the need
>> to explicitly define topics of relationships and associated trust values.
>>
>> I think that the latter issue (assigning trust values to relationships)
>> as this appears to becoming especially important now that work within
>> the Semantic Web community is moving towards trust.
>>
>
> Quick thought here - though I've written about it a little before - is
> that a flexible Groups mechanism takes off some of the pressure to
> explicitly define direct interpersonal relationship types. Instead we
> let users enumerate various kinds of group that make sense to them. So
> rather than create inSameBookClubAs relations between Alice and Bob, we
> allow Alice and/or Bob and or the Book Club to write a description of
> the people in that group. Having a first class object (the group)
> provides also an extensibility hook for additional properties. As often
> noted, this is hard with simple flat RDF triples...
>
> Dan
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>
>
Dan,

Yes, this is what I mean by: policies.

A user should be able to identify themselves (since they know themselves
best) via FOAF+SSL based Web IDs. They should also be able to construct
"data space" specific policies that deal with access, trust, and
reputation as perceived through the lenses of  the data space owner's
world view etc..

--


Regards,

Kingsley Idehen       Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software     Web: http://www.openlinksw.com




_______________________________________________
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