Re: N3 contexts vs RDF reification

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