- From: Lee Jonas <lee.jonas@cakehouse.co.uk>
- Date: Wed, 25 Apr 2001 18:00:45 +0100
- To: "'Seth Russell'" <seth@robustai.net>, RDF-IG <www-rdf-interest@w3.org>
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) I would have been more bothered by occurrences of what should be the same statement being assigned different statement ids. But your next bit means this is not what is happening: >> Also, you have to explicitly identify all statement occurrences >> consistently, even across documents - this could prove yet another problem >> for generating valid rdf. > >Well actually I am not proposing any changes in RDF\XML or the RDF data >model whatsoever - so my proposal would have nothing to do with validating >RDF. Rather my proposal addresses the internal data structure of a >application ... I guess you could call it the RDF API. > Ok. >> Rather than an 'artificial key' for statements, what if the key were >> regarded as (p,s,o)? >> then >> (c1,p1,s1,o1) >> (c2,p1,s1,o1) >> represents two contexts referring to the same statement. The consumer of >> statements is free to 'import' them into their own contexts if they wish: >> (c3,p1,s1,o1). > >Cool! I hadn't though of that. In this regard our proposals are almost >identical. And in my application I actually do form the key p+s+o to insure >that a potentially new triple does not already exist before I store it in >the database enforcing the idealistic view that triples are unique. > Arguably, you are storing the ephemeral statements, whereas all triples generated from parsing the RDF/XML are *occurrences* of said statements. >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): CREATE TABLE contexts(ID INT PRIMARY KEY); CREATE TABLE statements(ID INT PRIMARY KEY, ...); CREATE TABLE contexts_statements_xjoin(ContextID INT, StatementID, PRIMARY KEY(ContextID, StatementID)); Then, I can determine which statements are in which contexts from 'contexts_statements_xjoin'. I.e. I don't need extra statements in the RDF Model to determine context membership, either from the quadruples or direct from the database. I am doing something like this in a new project I am working on, so it will be interesting to see if it works out ok. Perhaps more on that later... >And also I don't understand how you have solved the reification problem .... >[previously you mention] >> It seems to me that the goal of reification is to make further statements >> about statements - i.e. make statements the subject or object of other >> statements. > >I can see how we can use your technique to make statement(s) the subject or >object of other statements. But what about just one statement ? For >example I can say (c1,p1,s1,o1) and (c1,p2,s2,o2) and then talk about those >with (c2,p3,c1,o3) but what if I just want to talk about the second >statement alone .. how would I do that? > By creating a new context, c3, containing an occurrance of the second statement - i.e. (c3,p2,s2,o2). >thanks for the dialogue ... >Seth You're welcome. regards Lee
Received on Wednesday, 25 April 2001 13:00:41 UTC