- From: Karsten Otto <otto@math.fu-berlin.de>
- Date: Sat, 20 Dec 2003 15:00:26 +0100 (CET)
- To: Chris Bizer <chris@bizer.de>
- Cc: Jeremy Carroll <jjc@hpl.hp.com>, <www-rdf-interest@w3.org>
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