gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] PEG model_management--tjl


From: Matti Katila
Subject: Re: [Gzz] PEG model_management--tjl
Date: Wed, 2 Apr 2003 22:53:05 +0300 (EEST)

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++;

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

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

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.


------------------------------------

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           


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

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


   -Matti





reply via email to

[Prev in Thread] Current Thread [Next in Thread]