W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2002

Re: Contexts? (again)

From: Seth Russell <seth@robustai.net>
Date: Thu, 21 Nov 2002 06:18:36 -0800
Message-ID: <3DDCEB3C.7060609@robustai.net>
To: Danny Ayers <danny666@virgilio.it>
CC: www-rdf-interest@w3.org, tarod@SoftHome.net
Danny Ayers wrote:

>>Could there be a better way to describe that the data came from a
>>certain source?
>>    
>>
>
>So we've got
>
>m1{
>	S1
>	S2
>...
>}
>
>
>(Sx is a statement in tonight's syntax)
>
>and
>
>m2{
>	S3
>	S4
>...
>}
>
>  
>
It seems to me that the easiest way to do that is to give each statement 
its own identity (sequence number, whatever) when it is parsed into a 
graph.  [I changed your quoted example to do that]   This would take us 
from a quad to a pent. But hey, memory is cheep, the complexity of 
programming reification (and deReification) all over the place takes a 
lot of time.  I think an arrow can have as many attributes as the 
application deems necessary.  So with a pent arrow {graph, subject, 
property, object, stId} your example would look like:

m1,  m2 , are just as you have drawn them above, except that I have 
given each arrow its own serial number.

So the aggregated graph could be:

m3 { S1  S2  S3  S4 }

and we could keep the memory of where the Sn came from in a separate 
provenance graph:

m4  {Id1 isFrom m1.  Id2 isFrom m1.   Id3 isFrom m2.  Id4 isFrom m2}.

Note that the IdN are just internal identity strings, kind of like a 
bNode identifiers only they identify statements.  Putting the identity 
of  an arrow as the subject of another arrow  (internally in the 
application) is the easy way of doing reification.  

There are 2 cases where we have problems:  

1) If the subject, property and object of two arrows are identical.  
2) If one graph is quoting the other graph -- the "Did Lois know that 
Clark was superman" problem.

I think the solution of those two problem emerges at the dialogue level 
when someone (or some process) asks that the two graphs be merged.  The 
user's choices would govern which StiId(s) are carried into the merged 
graphs, or whether the merged graph retains the subgraphs.  Different 
methods on the graphs would yield different results:

 - update might just take the latest StId,   
 - log might keep all StId(s) and yield a untidy graph
 - quote might  make a subgraph

But since we have named each graph (have a uri as it were for each 
graph), then we can talk at the meta loevel about those graphs.  We can 
say something like {m3  type untidyLog} or {m3 type updatedContext}.  I 
dont think this kind of solution  requires any change in the core ideas 
for the external RDF language.   It only requires that we agree on a way 
to give graphs uris.  Is that the rub?

language:  semenglish
(mentography primer)
    comment "describes arrows";
    url <http://robustai.net/mentography/Mentography.html>;
    author (seth russell).
Received on Thursday, 21 November 2002 09:19:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:57 GMT