Re: Trust, Context, Justification and Quintuples

http://www.wiwiss.fu-berlin.de/suhl/bizer/trustcontextjustification/

Chris

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.

2)
I feel you confuse implementation issues and abstract representation issues. 
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.

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

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.

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

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

Jeremy

Received on Friday, 19 December 2003 15:18:07 UTC