[Z3lab] concepts for the concept map

[Paul Everitt]

On May 20, 2005, at 10:45 AM, Janko Hauser wrote:

> Florent Guillaume schrieb:
>
>> On 19 May 2005, at 13:12, Janko Hauser wrote:
>>
>>>
>>> Point is that if we have something like a repository api for the
>>> applications managing content, it is much easier (in my humble  
>>> theory)
>>> to connect some other repository as a storage option beneath the  
>>> main
>>> repository.
>>>
>>> BEA has some nice views how they have build there storage system.  
>>> But
>>> we need to think, what ZODB alas instant object store, gives us,  
>>> what
>>> they need to build. The other big systems just start to think about
>>> object persistency, we use it all the time.
>>>
>>
>>
>> Could you detail a bit BEA's views about the storage system ?
>>
>>
> Hello, I have looked at this document:
>
> http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html
>
> Basically they use the term "virtual repository" as the application
> part of an repository. This application manages different kind of
> storages. The storages or subrepositories are storing SPI's which
> looks like node objects with attached schemas.
> The repository there has the responsibility of node selection, search
> and also hierachical relations. Which makes me wonder.
>
> In our concept in union.cms we think of the content in the
> contentrepository as a set of content objects, each content object is
> described by a schema. These are connected by relations. We use
> special content objects, which just structure the content objects. So
> for example a document holds an ordered list of relations to other
> content objects in the repository.

> In a site we mainly hold relations from pages (web page) to the
> structure objects (document) in the repository. I think the usage of
> hierarchical storage as representing relations between documents and
> content is not suitable for a repository, as it would hinder the reuse
> of the same content object in different documents.

I agree.

2 months ago I saw a demo of Mark Logic's Content Interaction  
Server.  Quite eye-opening.

It runs as a CGI which sends XQuery requests to the repository.  This  
means the web part is utterly stateless.  Even with huge piles of  
content, the performance is...well, insane.  Mark Logic was started  
by some Google folks that felt structure was useful.  As such, Mark  
Logic is voodoo magic. :^)  Berkeley DB XML has a similar (though  
more data-oriented) approach.

With this, the repository has no structure until you ask it a  
question, at which point, it has a structure.  It has no schemas, as  
you might want one resource to be valid based on different ways  
(schemas) to think about it.

The closest we have to this is Zemantic.

A repository should be the place where 10 year commitments are made.   
Right now, if someone gave me a ZODB from zope.org from 3 years ago,  
I'd have to jump waaayyy through my butt to get any of the business  
information out of it.  Actually, I could jump all I wanted, I'd  
still fail.  I'd have to pay Sidnei or Jens to do it for me.  That  
ain't good.

I'd love to have a repository like Berkeley DB XML or something  
similar where, even if I changed CMS, app server, programming  
language, schema design, business rules, whatever, in 10 years, I  
have a shot at getting out the data using a thinner stack of  
dependencies.  (Berkeley isn't all the way there, but is closer than  
what we have).

Repository == stable, long-term bet on business information, without  
application semantics.

> So we have the following structure.
>
> page -> publisher -> repository -> storage -> content object
>
> One word to the publisher. I thought that is would be a good idea to
> have something like a view for the repository, which can be
> application specific. The retrieval of objects in the current
> implementation is naturally by uid or by some kind of search into the
> repository catalog. I didn't want that applications need to build

I agree on application, but should the query be in the framework or  
in the repository?  I don't think the semantics should go in the repo.

> queries. Also a publisher keeps the API of the repository small, but
> not limited, as the API can be expanded by a new publisher. I used
> this for the inclusion of selective versioning.

I'm pretty sure I know where you're going with this, and I *think*  
Florent is going the same way.  Can you sprint with him in Sweden?

--Paul