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

[Sebastian Tramp]

On Wed, Oct 05, 2011 at 09:55:37PM +0200, Henry Story wrote:

> >> 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.

Indeed, and our policy is to trust only triple about the person as
subject. This is a strong simplification but its very practical if your
knowledge about the used vocabulary is very limited and if you have
limited reasoning support in your application.

> >>> 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

Thanks for the link, is beatnik the new name for your sommer adressbook
(or the old?)

> 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.

Yes, Linked Data emphasizes the Web in "Semantic Web" ...

> 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.

Best regards

Sebastian Tramp

-- 
WebID: http://sebastian.tramp.name