RE: [Zope-dev] RFC: RelationAware class for relations between obj ects
My observations from a digital-media management perspective lead me to believe that relationships and other metadata are closely intertwined, and that there needs to be a way to righcly express metatdata about relationships. One the subject of simplicity vs. features - it should be said that one thing that high-level applications would likely need to bolt on top of these relationships is metadata about those relationships. In the keep-it-simple model the descriptor names (Python identifiers, ie self.developers referencing a relation object) serve as an id for one half of the relationship, but how does one attach to following to that half of the relationship: - relationship type/model (same as DCMES relation qualifiers) - relationship label/plain-text-title - content type or class of related object - id/reference or path to content - potentially some other data? Examples (warning: long post): http://mail.zope.org/pipermail/zope-cmf/2002-October/015801.html In a keep-it-simple model, where does this high-level stuff belong? In a global service? Sean -----Original Message----- From: Jeremy Hylton [mailto:jeremy@zope.com] Sent: Tuesday, April 29, 2003 7:52 AM To: Steve Alexander Cc: Shane Hathaway; roche@upfrontsystems.co.za; zope-dev@zope.org; maxm@mxm.dk Subject: Re: [Zope-dev] RFC: RelationAware class for relations between objects On Tue, 2003-04-29 at 09:59, Steve Alexander wrote:
There's a way to allow a descriptor (or other thing defined inside a class suite) to do things to the class immediately after the class is created.
Boy, that's a lot of mechanism. It would be nice if the relation support could be kept simple. Jeremy _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Le Mardi 29 Avril 2003 17:32, sean.upton@uniontrib.com a écrit :
My observations from a digital-media management perspective lead me to believe that relationships and other metadata are closely intertwined, and that there needs to be a way to righcly express metatdata about relationships.
I completely agree. This is exactly how we implemented relations in ERP5. Actually, there is an isomorphism between 2 concepts - categorisation - relations Categorisation is in the world of metadata. Relations is apparently in a different world but, with the help for example of acquisition, the two worlds can be made one, by making sure categories are a kind of object.
One the subject of simplicity vs. features - it should be said that one ..... In a keep-it-simple model, where does this high-level stuff belong? In a global service?
This is also how we implemented things in ERP5. With - a portal tool which implements core methods for categories and relations - a Base class which provides aliases and simplified access to categories / relations - a utility system which generates on the fly some relation methods so that one can write someting like object.getDefaultSource() where 'source' is the id of a relation (1 -> n). For more info, please read http://www.erp5.org/erp5/wiki/guide/RadERP5 http://savannah.nongnu.org/cgi-bin/viewcvs/erp5/ERP5/PropertySheet/PropertyS... The system is currently running in a factory in Europe and North africa (it is an open source ERP based on Zope). It is rather reliable. One of the reasons why we chose this approach (ie. implement relations as metadata of objects rather than uids / central repository) is because we need to synchronize content accross multiple sites (each of which has potentialy a different set of classes and a different version of ERP5). We use the syncml protocol for this purpose. Because we do not use uids, it is much easier to exchange / synchronize relations (or partial relations) accross multiple zope sites. If we had done it another way, it would have been much more complext to handle. We also implemented a consistency system which finds inconsistencies accross the database and eventually fixes them. We still have a lot of work on this issue. One reason it is not that simple is because we want to be able to have both relations and partial synchronization between multiple sites. This makes usual consistency methods not much adapted to this situation. Also, we wanted to follow a documentary approach for relations and we through that metatada was one of the closest way to implement relations in a content mangement system. I hope this helps. JPS. -- Jean-Paul Smets-Solanes Nexedi CEO Tel. +33(0)6 62 05 76 14 Fax. +33(0)1 53 01 09 29 About www.nexedi.com Nexedi is a consulting and development services company helping small and medium organisations to choose open source / free software and fulfill their IT application needs. Nexedi is the founder of the ERP5 project, a Free / Open Source ERP software based on innovative technologies (www.erp5.org). About www.storever.com Storever provides a reliable source for OpenBrick, WiFi infrastructure, notebooks and servers preconfigured with the GNU/Linux operating system
participants (2)
-
Jean-Paul Smets -
sean.upton@uniontrib.com