[foaf-protocols] Person <-> Group (+sub/related groups) relations...

[Henry Story]

On 5 Oct 2011, at 21:21, Sebastian Tramp wrote:

> On Wed, Oct 05, 2011 at 06:26:12PM +0200, Dan Brickley wrote:
> 
> Hi Dan,
> 
>>> Hi pavlik, foaf itself lacks a isMemberOf poperty. We use
>>> http://open.vocab.org/terms/isMemberOf instead.
>> 
>> Can you elaborate on why you need a relationship named in this
>> direction? Rather than myGroup having a :member link to a person?
> 
> In a distributed scenario, where both descriptions (the person WebID and
> the group WebID) are published by different authorities, we often choose
> to trust only in statements which have the subject = the linked data
> resource in our implementations. In the membership case here I would
> finally relate the group and the member only if both parties accept the
> relation (by publishing it). This can be much more complicated (e.g.
> refer to dgFoaf [1])

This sounds like an error. It is not the directions of the arrows that matter with regard to trust, but who says what - and then how much we trust them on the topic in question. So it is very important to keep track of who is asserting the graphs. 

Can you give an example where this would not be the case?


> 
>>> There is a proposal to add this to the relationship vocab:
>>> http://wiki.foaf-project.org/w/Using_Relationship_vocabulary
>>> 
>>> but Ian Davis and Eric Vitiello Jr did not changed that so far ...
>>> 
>>> using the the member relation in your own webid is imho not a good
>>> idea, because some clients filter out statements which are not in
>>> the cbd of the linked data resource ...
>> 
>> Clients that assume property naming direction is important are broken
>> and should be fixed. Whether we write: book1 author person2 . or
>> person2 wrote book1 . ... shouldn't matter; they are both 'about' the
>> book and the person equally.
> 
> I agree if we talk about a scenario where you have one application
> wide RDF store which you can totally trust. When our application has
> to consume Linked Data from untrusted sources it is complicated how we
> handle incoming data, e.g. if we want to see them in the context of
> the rest of the applications knowledge base. For sure you could lock
> incoming data in named graphs, each for one linked data resource - this
> is maybe a solution but difficulty to handle and does not solve the
> problem if you need to merge the data to have an overall view. OntoWikis
> Linked Data consuming extension works fine with this strategy.
> 
> Do you have any hints or example applications which implement other
> strategies to solve this problem?

"Beatnik: change your mind"
http://blogs.oracle.com/bblfish/entry/beatnik_change_your_mind

The problem of intentional contexts is a core philosophical/logical concept. This appears very much in the semantic web, but the current linked data people have not taken it seriously enough. The semantic web allows us to merge information, but does not force it. There will be interesting rules though as to when we merge and don't merge information that I am sure will come out of using and thinking of this issue.

Henry

> 
> Best regards
> 
> Sebastian Tramp
> 
>  1. http://www.uni-koblenz-landau.de/koblenz/fb4/AGStaab/Research/systeme/dgfoaf
> 
> -- 
> WebID: http://sebastian.tramp.name
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social Web Architect
http://bblfish.net/