Re: [foaf-dev] privacy and open data

Hi Philip,

I am forwarding this (with a few remarks) to the semantic web mailing  
list, to get the responses from a larger audience.

On 25 Mar 2008, at 12:27, Phillip Rhodes wrote:
> Story Henry wrote:
>> Dear Semantic Web community,
>>  1. either return different representations of the requested  
>> resource depending on who is viewing the information
>
> This is along the lines of what I'd been considering for OpenQabal,  
> but
> to be honest, I haven't put a lot of thought into it yet.

For more info:
https://openqabal.dev.java.net/

Btw. I am doing a presentation of Beatnik, the semantic Address book,  
at JavaOne (one of 3 semantic web presentations ).
see the info and picture at the end of http://blogs.sun.com/bblfish/entry/opening_sesame_with_networked_graphs
It would be great if I could do a demo with Beatnik and OpenQuabal,  
that would follow some simple convention like the one discussed here.

>>  2. have different resources be responsible for different subsets  
>> of the data and create rdf:seeAlso links between them. Some of  
>> these resources would only be accessible to certain user agents (UA).
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>
> Interesting approach.  How well defined are the semantics of seeAlso  
> now? Would this conflict with the intended use of seeAlso or with  
> anything that's already in use in the wild?

Perhaps we would need a subrelation of seeAlso. a moreinfoAt relation  
of some sort.

> I'm also trying to think of how querying would work with this.  Let's
> say I want to query "my social graph" out to depth n, to see if I'm
> connected to someboby named "John Doe."  Any thoughts on how something
> like that might fit in with either of these approaches?

There are two pieces. All the client  ( such as Beatnik ) needs to  
understand is that more info is available at some
resource and how to get the rights to that resource.

On the server side there are any number of ways to work out if the  
client has rights to the service.

   - The simplest would be simply for the server to have a list of  
authorised openids that can access the resource
     This is a little tedious for the maintainer of the openid

   - more flexible may be to just for the server to periodically crawl  
a person's foaf file and gather links to resources up to n depth
     and allow all people identified via an openid to see the full view.

   - after this one can imagine more and more subtle ways of grouping  
people:
      +  friends one trusts
      +  family
      +  colleagues: people who have openids whose authentication  
server is a specific server
         see: http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun

I would like to first cover the simplest and most common cases. Even  
just one of these would be ok to get going:

   - friends of friends
   - colleagues
   - family



>
> Hmm..  thinking about it further, that question would probably depend
> on whether the total data to be queried was spread across multiple
> completely unrelated domains, or if some or all of it was on servers
> that had an agreement to "talk" to each other via another channel.
> If the former, there's not much choice but to grab the FOAF,  
> dereference
> links as necessary, load more FOAF, query, lather-rinse-repeat. If  
> it were the latter, the server that received the initial query could  
> use
> whatever means it has, do the query and just return the correct FOAF  
> (or an error code).

Right. The server can use whatever data it has, and policies it wants  
to follow, to give or refuse access to certain resources.
There is no need really to have an exchange format for specifying  
these policies.

There may be a need to specify to the client if he should be bothered  
to try to access a resource, especially if as with openid,  
identificiation is a little bit complex.

Thanks,

	Henry

PS. Please give me a call at one of my numbers available from my home  
page at http://bblfish.net/ . Our two projects are very complimentary.


>
>
> TTYL,
>
> -- 
> Phillip Rhodes
> Chief Architect - OpenQabal
> https://openqabal.dev.java.net
> LinkedIn: http://www.linkedin.com/in/philliprhodes
> <mindcrime.vcf>