Re: Contexts? (again)

As the complexity increases, graphs are less and less useful, and language is the only way to go.  A picture may be worth 1,000 words, but it's not very useful if you have 10,000 words.
============ 
Dick McCullough 
knowledge := man do identify od existent done
knowledge haspart list of proposition

  ----- Original Message ----- 
  From: Seth Russell 
  To: Danny Ayers 
  Cc: www-rdf-interest@w3.org ; tarod@SoftHome.net 
  Sent: Thursday, November 21, 2002 6:18 AM
  Subject: Re: Contexts? (again)


  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).