Re: Trust, Context, Justification and Quintuples

Hello,

I have a problem with Jeremys conversion to named graphs. Assuming
I somehow found this triple within my collection of named graphs:

<eg:MonicaMurphy eg:hasSkill eg:JavaProgramming>

How do I find out that it was asserted in graph _:S2341 ?
In the same manner, if I found another triple, how do I find out
it was something eg:Chris eg:said on eg:date "2002-12-10", that
is, it is contained in the eg:SayingEvent whose eg:content is
the named graph _:C1303 ?

Well, I could look at every named graph I have and see if the triple
is contained in it, but this seems rather inefficient to me. The problem
is that the node->graph map only supports "forward resolving", while
Chris' quintuple statings also support "backward resolving".
Or did I get this wrong? How do I solve this problem properly with
named graphs?

Regards,
Karsten Otto

Original message follows below:

> 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 09:03:29 UTC