Re: [Gzz] PEG model_management--tjl

[Tuomas Lukka]

On Wed, Apr 02, 2003 at 10:53:05PM +0300, Matti Katila wrote:
> 
> Very interesting PEG since I have been doing mostly about the stuff for 
> zz->rdf port and have even something to say :)
> 
> On Wed, 2 Apr 2003, Tuomas Lukka wrote:
> > The Space system was hastily ported from Gzz for the demo deadline.
> > It needs rethinking.
> 
> Definitely.
> 
> > - Why the abbreviated name?
> >     RESOLVED: This is a name that will be written SO often
> >     that acronymizing it is appropriate. All views &c will
> >     carry an instance of this class.
> 
> Heh, once I though something close to fen and it was boghole ;) 
> Of course class Fen would be a good short alternative also. Funny++;

I like it...

> > - Do we really need the "home" member in FFC?
> 
> Good question. If we do we don't have to use it. In zz like views it could 
> be good startting point but not very needed by other views I think.

Hmm... I guess the consensus was no need.

> > In Gzz, a Cell was bound to its Space, and Space also provided the 
> > facilities for
> > getting a Cell's content. ...
> > ...
> > For Fenfire, we do still need some abstract notion of a node's content; 
> > basically,
> > a mapping between nodes and enfilades, as well an index for use in xu links.
> 
> Yes, I have been too busy to write to gzz-dev how did I solve this in the 
> current state of SimpleVStreamer and AbstractSpace.
> 
> Well, maybe it's time to tell.
> 
>   
>     Node(think this --ALPH.clone-->DataNode --ALPH.data-->Literal()
>      |   as a cell                   |                       <alph:: span, 
>      |   found from                  |                         start=10,
>      |   zz)                         |                         end=100 /> 
>      |                               |                           
>   RDF.type                        RDF.type
>      |                               |
>      |                               |
>     \|/                             \|/
>    ALPH.cloneType               ALPH.dataType
>                                      |
>                                      |
>                                      |
> In VStreamer:                      datanode is the key to map  the enfilade
>                                    This is the place where orthogonal
>                                    structures join.
> 
> 
> So every node is kind of a clone 

Could you please first define *WHAT* a clone is? 

Lots of words on the diagram, none of which mean anything to me. 
datanode is the key to *WHAT* map???

Why are there datanodes at all?

> and no Space.getRootCell is needed. You 
> can't tell if some of clones has been created before or after your node.

???

> Space.clone(RDFNode node) clones node if it even has ALPH content.
> Or actually linking is done to data node.

Again, this makes no sense to me since cloning is not defined.

> To be implemented:
>   DataNode's literal handling.
>     -should not be saxed out everytime when the content changes.
>     -collect changed nodes to map etc.
>
> So, we are now able to use *alph* or *normal* literal/resource content. 
> this is advantage since most of current RDF users doesn't know much about 
> alph.

How? I don't understand the design to understand that.

> 
> ------------------------------------
> 
> Xulinks:
>  
>          __...--ALPH.xuLinkTo-->   to ---RDF.type---> ALPH.xuLinkType
>   id ---<__                         |
>    |       '''--ALPH.xuLinkFrom--> from --RDF.type--> ALPH.xuLinkType
>    |                                |
>    |                                |
>  RDF.type                           |
>    |                  In VStreamer: |
>    |                                |
>   \|/                             node is used as a key to map to enfilade
> ALPH.xuType           

Yes, this is reasonable.

Ah, right, since the content can be put in using different properties, there's
no need to keep these separate in the default model!

> > One alternative would be to wrap RDFNodes into Cell-like objects but that 
> > would
> > be very inefficient as well as inelegant.
> 
> If I understood correctly, forget it ;)

Indeed. ;)

> > I propose the following FFC (FenFire Context) class::
> >     package org.fenfire;
> >     class FFC {
> >     public jena.Model model;
> >     RDFNode home; 
> > 
> >     NodeContent content;
> >     
> >     EnfiladeOverlapIndex enfiladeOverlap;
> >     XuIndexer xuLinks;
> >     }
> > 
> > (replace ``jena.`` by ``com.hp.hpl.mesa.rdf.jena.model.``)
> > This class would be frozen at birth.
> > at the same time, remove for now IndexManager.
> 
> Seems to be very same as AbstractSpace currently is ;)

Except that enfiladeOvelap and xuLinks are directly there.

Yes, it's a similar concept but I'm trying to make it fit a little better.

> > The org.fenfire.NodeContent interface is defined as follows::
> > 
> >     class NodeContent {
> >     /** Get the vstream in this cell.
> >      *  Never returns <code>null</code>.
> >      */
> >     Enfilade1D getEnfilade(RDFNode node);
> > 
> >     /** Set the vstream in this cell.
> >      */
> >     void setEnfilade(RDFNode node, Enfilade1D vstream);
> >     }
> 
> setEnfilade sounds a bit of low level even it's absolutely the right way.

I do not understand your sentence at all ;)

        Tuomas