Re: Trust, Context, Justification and Quintuples

Hi Jeremy,

thanks for your comments and see below ...

>I looked at your paper and had a few comments ...
>(I stopped when you got onto QLs, not really my scene)
>
>1)
>[[
>the context identifier, which is a context identifier
>the stating identifier, which is a stating identifier
>]]
>
>it is simpler to say that these are both  "RDF URI reference, or a blank
>node," and delete the context identifier and stating identifier as a type.
It
>then may schema information that there is a type crdf:Stating and a type
>crdf:Context with appropraite schema inference rules.
>
OK. I was first following Dave Beckett's approach from
Redland(http://www.redland.opensource.ac.uk/notes/contexts.html)  modelling
identifiers as seperate objects. After Karsten Otto gave me the same hint as
you did, I moved the identifiers into the model and wrote the cRDF vocab. I
just forgot to delete the "which is a context identifier".

>2)
>I feel you confuse implementation issues and abstract representation
issues.
Confuse or mix :-) Thinking more in terms of data base than knowledge
representation, I tried to look simultaneously at representation,
implementation and convenient querying. That's why I tried to design cRDF as
implementable logical model on top of RDF.

>Both the context identifier and teh stating identifier associated a name
>(local or global) with a triple (s, p, o) you really only have quintuples
if
>there is an interesting relationship between the two - if not, abstractly
you
>just have two quadruples with a way of writing them down compactly.
>Moreover if the relationship between a stating identifier and a context
>identifier is predictable then probably there is no need for the two
concepts
>either.
>
On the representation level, you are right. For contexts one could use a
container with stating IDs. But when it comes to querying, I think it is
much more convenient to have context identifiers directly linked to a
stating than having containers. See MacGregor's query example
(http://km.aifb.uni-karlsruhe.de/ws/psss03/proceedings/macgregor-et-al.pdf)
or cQL.

>My take on this, with the named graph approach is that a stating is a named
>triple, i.e. a named graph of one triple.
>
>Thus what you have as
>
>eg:MonicaMurphy
>eg:hasName
>"Monica Murphy"
>C1300
>S2340
>
>eg:MonicaMurphy
>eg:hasSkill
>eg:JavaProgramming
>C1300
>S2341
>
>eg:MonicaMurphy
>eg:hasSkill
>eg:WebDesign
>C1300
>S2342
>
>I would express as the following set of named graphs
>
>_:C1300 =>
>{ <eg:MonicaMurphy eg:hasName "Monica Murphy">
><eg:MonicaMurphy eg:hasSkill eg:JavaProgramming>
><eg:MonicaMurphy eg:hasSkill eg:WebDesign> }
>
>_:S2340 =>
>{ <eg:MonicaMurphy eg:hasName "Monica Murphy">}
>
>_:S2341 =>
>{ <eg:MonicaMurphy eg:hasSkill eg:JavaProgramming> }
>
>_:S2342 =>
>{ <eg:MonicaMurphy eg:hasSkill eg:WebDesign> }
>

You say a context consists of several *statements* . I say a *stating*
belongs to a context.
You are demonstrating the difference between the two definitions with the
Fred, Wilma, Barney example below.

>I have introduced many fewer new concepts than you (only one, instead of
about
>four), which I see as quite a big gain. The fewer primitive concepts the
more
>likely we will get it right. I think that when we were expecting statings
to
>be important we could optimize an implementation of named graphs to also
>support named triples as well, and effectively the implementation would be
>the same as for your quintuples but just with a different skin API.
>
Interesting. But then the question is again, which API is more convenient in
which context.
I'm thinking again about querying and also about justification
http://www.wiwiss.fu-berlin.de/suhl/bizer/trustcontextjustification/#justifi
cation.

>I think also that the semantics of the named graphs is fairly easy to grok.
>An interpretation of a set of named graphs is an RDF Semantics
interpretation
>I of all the graph simulataneously such that that I(n) = g for every <n,g>
>where n names g. (i.e. the graphs as graphs are in the domain of
discourse).
>
>I still need to introduce some vocab items to correspond to your idea of a
>context identifier. e.g. I need  a class crdf:Graph and I(n)=g entails  n
>rdf:type crdf:Graph.
>
>Hmmm, on further examination my semantics differs from yours.
>You can have many different contexts with the same triples (and presumably
>different statings with the same triple), whereas my semantics strongly
>identifiers the name with the set of triples. In my view both of these are
>needed, (the old statement vs stating controversy). Don't I trust a
statement
>rather than a stating i.e.

Yeap. I thing this is the most important point. You trust a statement
because it has been stated by somebody you trust or it has been stated in a
context which (you think) makes it likely that the statement is true. In an
distributed environment you do not trust anything without having some
provenance information about it .

>if fred says (a b c) and wilma says (a b c) and barney says (a b c) then
>maybe, despite not trusting any one of them, I might believe (a b c).
>How does that work with your stating mechanisms - I don't believe the
stating
>that fred said, nor that that wilma said nor that that barney said, but I
>believe yet another stating with the same content - and that content is the
>quoted triple.
>
I see two possibilities: There might be another stating from Ralf and you
might use a Web-Of-Trust mechanism which includes Ralf. So you believe the
content of Ralfs stating and ignore the others. The other possibility is
that you believe a fact for reasons outside the model and you want to
include this knowledge into the model and into your conclusion based on the
model. For this you would include statings made by yourself into the model.

>The example you give of dated saying events is also compelling - and can be
>shown using a naming mechanism with an extra property indirection
>
>eg:Chris eg:said _:b .
>_:b rdf:type eg:SayingEvent .
>_:b eg:content _:C1303  . # the name of the said graph
>_:b eg:date  "2002-12-10" .
>

Ok here I think, the difference between our approaches is that you are using
two separate layers and I'm using just one. You are having a layer of named
graphs and a layer of sayings or statings of these named graphs.  I'm mixing
both on the statement level.
We should try to find out which approach is more appropriate for which
applications.

Altogether, really an interesting discussion :-)

Chris

>Jeremy

Received on Saturday, 20 December 2003 07:20:17 UTC