- From: Seth Russell <seth@robustai.net>
- Date: Thu, 26 Apr 2001 07:28:54 -0700
- To: "RDF-IG" <www-rdf-interest@w3.org>, "Lee Jonas" <lee.jonas@cakehouse.co.uk>
- Cc: "Tim Berners-Lee" <timbl@w3.org>, "Guha" <guha@alpiri.com>, "pat hayes" <phayes@ai.uwf.edu>
From: "Lee Jonas" <lee.jonas@cakehouse.co.uk> > Seth Russell [mailto:seth@robustai.net] wrote: > > >From: "Lee Jonas" <lee.jonas@cakehouse.co.uk> > > > >> I like the concept, but does it mean n+1 tuples? e.g.: > >> (stmtid1,p,s,o) > >> (stmtid2,references,ctx1,stmtid) > > > >Yes, but I don't see that as a problem, do you? > > Actually, it becomes n+n*m tuples (worse-case), e.g.: > > (stmtid1,p1,s1,o1) > (stmtid2,p2,s2,o2) > (stmtid3,ref,ctx1,stmtid1) > (stmtid4,ref,ctx1,stmtid2) > (stmtid5,ref,ctx2,stmtid1) > (stmtid6,ref,ctx2,stmtid2) > > This bothers me ever so slightly (though not a lot): my proposal would not > fare much better at n*m: > > (ctx1,p1,s1,o1) > (ctx1,p2,s2,o2) > (ctx2,p1,s1,o1) > (ctx2,p2,s2,o2) Well yes my proposal definitely stores more records. However, depending on implementation, it may actually store the same amount of data. Consider a case where we are just concerned with context but don't want to do second order reasoning about that context, then we are permitted to factor all of the context arcs into another table and can eliminate the statement id on those arcs. This may have the added benefit of making the SQL queries easier .. but I'm not sure yet. So we end up with: (stmtid1,p1,s1,o1) (stmtid2,p2,s2,o2) (ctx1,stmtid1) (ctx1,stmtid2) (ctx2,stmtid1) (ctx2,stmtid2) Which stores exactly the same amount of actual data as your proposal. Please refer to the mentograph at http://robustai.net/mentography/SemStructure.gif > Arguably, you are storing the ephemeral statements, whereas all triples > generated from parsing the RDF/XML are *occurrences* of said statements. Yes. I like to think of it as storing the ~ideal~ statements and then allowing different contexts to view them. > >However, the extra tangible arc label assigning the triple to a context > >proves useful for other reasons in my system. With it one can talk about a > >statement being in a context ... and that statement being in a context ... > >and so on .. and so on .. and so on. With your system there is no such > >explicit arc of which we can speak. > > No, but that information is captured directly in the quadruple. I can map > quadruples into 3 tables (and vice-versa): Yes, I understand. I think our methods are different only in the direction of the context arrow .. please refer to the mentograph at: http://robustai.net/mentography/orthoganilizingContext.gif But, as acknowledged, with you proposal there is no arc label for context, therefore there is no explicit link to a property node for that concept. It seems that whatever is done with your context will need to be hard coded into the system; it could not be specified via a schema. But to be honest I think your technique has more aesthetic appeal ... it feels cleaner .. I like to think of context as a container ..... so now I am wavering. I had originally planned to do it your way, then somebody convinced me that drawing the arcs in the opposite direction would be more flexible. Help! .. Help! .. Help! ... decisions .. decisions ... decisions .... Seth
Received on Thursday, 26 April 2001 10:33:13 UTC