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

Matthew Rowe m.rowe at dcs.shef.ac.uk
Thu Jun 25 12:19:09 CEST 2009


Hi Olaf

Thanks for the comments.

On 25 Jun 2009, at 06:14, Olaf Hartig wrote:

> Hey Matthew,
>
> On Wed Jun 24 14:37:39 CEST 2009 Matthew Rowe wrote:
>> On 24 Jun 2009, at 12:40, Melvin Carvalho wrote:
>> [...]
>>> Perhaps named graphs can help, or maybe storing an extra field in  
>>> a DB
>>> for the weighting?
>>
>> Yeh this is something I have been puzzled by aswell. Olaf Hartig's
>> paper on "Querying trust in RDF data with rSPARQL" [1] details that
>> RDF graphs can be trust weighted, and expresses individual statements
>> within the RDF graph as having trust values (ranging from 0-1).
>> However, the paper does not explicitly say how trust values would be
>> stored (ie. what the semantics would be for expressing a trust  
>> value).
>> As you suggested it appears that the db contains an associated trust
>> value with a given triple. I assume that in terms of assigning trust
>> values to relationships, trust values would be assigned to the
>> relationship triple:
>>
>> (<#Alice> foaf:knows <#Bob>) 0.9
>
> Just to make this clear, my trust values represent the  
> trustworthiness of RDF
> statements. There is a difference to trust values that represent the
> trustworthiness of persons. You should not confuse both. If you want  
> to
> represent the trust value associated with the relationship between  
> persons
> you must not assign a trust value to the relationship triple (as you
> suggest). Associating 0.9 to the triple
>
> :Alice foaf:knows :Bob

Granted, that was just a naive example I was using but I see your point.

>
>
> means the statement that "Alice knows Bob" can be trusted to a high  
> degree
> (considering a trust value of 1.0 is the upper bound). It does not  
> mean that
> Alice highly trusts Bob.
>
> BTW - Intentionally, I do not write about storing trust values (of
> statements!) in my paper because I assume in the majority of cases  
> these
> values do not have to be materialized. Usually, the trustworthiness of
> processed statements is determined on demand; i.e. when it is needed  
> in the
> application (or in the query engine in my case). At best these  
> values are
> cached for a while. I don't see no value in explicitly describing  
> them with
> RDF.

> However, for the unlikely requirement to materialize trust values  
> determined
> for statements (i.e. to explicitly describe the trustworthiness of  
> statements
> with RDF) I developed a vocabulary [1]. This approach is based on RDF
> reification.
>
> In contrast to trust values for statements I think it is reasonable to
> explicitly represent the trust values for persons (i.e. describe  
> these values
> with RDF). That's what you want to do, right? My vocabulary may be  
> used for
> this, too. Notice, in this case you don't need no reification. For  
> example,
> the statement Alice trusts Bob with trust value 0.9 can be described  
> as
> follows:
>
> :Bob tv:trustworthiness [ rdf:type tv:TrustValue ;
>                                       rdfs:value 0.9 ;
>                                       tv:truster :Alice ]

I like this form but I think there is an issue about how different  
people interpret trust. From a philosophical perspective when we say  
that we trust someone:

Do we simply trust someone in general? i.e. In the broad sense of the  
term? Alice trusts Bob
or
Do we trust a person given a context? i.e. Alice trust Bob's opinion  
on the Semantic Web

I am more inclined to say the latter. Is there are any way this could  
be included in your vocabulary as something like:

Bob: tv:trustworthiness [rdf:type tv:TrustValue;
					rdfs:value 0.9 ;
					tv:truster :Alice;
					tv:context <http://dbpedia.org/resource/Semantic_Web> ]


>
> Greetings,
> Olaf
>
> PS. Please CC me because I'm not on the list
>
> [1] http://trdf.sourceforge.net/trustvocab.owl



thanks again

Matthew Rowe, MEng
PhD Student
OAK Group
Department of Computer Science
University of Sheffield
m.rowe at dcs.shef.ac.uk



More information about the foaf-dev mailing list