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

[Henry Story]

On 6 Oct 2011, at 09:07, Sebastian Tramp wrote:

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

I think again here you seem to be confusing the triple level with the graph level. 
Perhaps have a look at my "Philosophy and the Social Web" talk at slide 78

http://www.slideshare.net/slideshow/embed_code/5583083?startSlide=78

(wait for the audio to download, the sound should start on slide 78 then).
 
The explanation is trying to be very simple, because it is one of those fundamental problems
that require a shift in thinking.

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

yes, that's was the name I was using for the AddressBook

  http://bblfish.net/work/AddressBook/

But I have not worked on it for a while... I got involved in the WebID issue
which needed solving.

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

yes, but on the web, like in the real world, we don't believe everything that everybody tells us.
That is what Tarski, and Donald Davidson thereafter, called the Disquotational theory of Truth. Truth is an operator that
takes a sentence and unquotes it:

 "The Eiffel Tower is in Paris" is True in English if, and only if, the Eiffel Tower is in Paris .

Or using N3

 { { :eiffelTower in :Paris } a log:Truth } <=> {  :eiffelTower in :Paris }

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

Social Web Architect
http://bblfish.net/