[Zope3-dev] Yet Another Relations (aka Reference) Engine...

[Jean-Marc Orliaguet]

Reinoud van Leeuwen wrote:

>On Fri, Nov 11, 2005 at 04:44:47PM +0100, Jean-Marc Orliaguet wrote:
>  
>
>>Reinoud van Leeuwen wrote:
>>
>>    
>>
>>>On Fri, Nov 11, 2005 at 03:50:25PM +0100, Helmut Merz wrote:
>>> 
>>>
>>>      
>>>
>>>>A relation is an object providing the IRelation interface. This 
>>>>has got two attributes ('first', 'second' - dyadic relation) or 
>>>>   
>>>>
>>>>        
>>>>
>>>I've done this kind of thing in relational databases. Problem with 'first' 
>>>and 'second' is that it seems to imply some order. And if I try to find 
>>>all relations from an object I allways have to compare my ID to either 
>>>first or second.
>>>
>>>I solved my problem by chopping a relation into three parts: the relation 
>>>itself and both endpoints. In my database this generated an extra table 
>>>(and some more work when writing queries), but the solution became more 
>>>generic and flexible in the end.
>>>
>>>(See the database diagram on 
>>>http://www.drbob.org/datamodel/drbob_datamodel.htm . The two endpoints of 
>>>a relation are stored in two object_link records, the relation itself in 
>>>one link record.) 
>>>
>>> 
>>>
>>>      
>>>
>>Hi!
>>
>>I think that you want 1 relation that consists of:
>>- the elements in the relation (the relates)
>>- the predicate
>>
>>then you can chop the relations into piece when you index it, but not
>>before.
>>
>>a relation is by definition 1 entity, if you start storing 2 items to
>>represent a single relation, you will have problems looming ahead when
>>it comes to managing the different "parts" of the relation. For instance
>>if you store A -> B and B -> A to represent A <-> B, you will have to
>>destroy A -> B if you remove B -> A.
>>
>>This is why I use real triadic relations to avoid having complicated
>>constructions based on  dyadic relations that only make sense when
>>they're taken together. When I destroy a triadic relation between 3
>>objects, this is done in one take, not three takes.
>>
>>then order in a relation is important:
>>
>>    A kills B
>>
>>is not the same as:
>>
>>    B kills A
>>
>>of course if the predicate is :
>>
>>   __ is like __
>>
>>it appears as though order is not important, but it is a question of
>>semantics, not a question of logic. A relation engine is not supposed to
>>know about semantics.
>>    
>>
>
>OK. In a relational database you can solve the 'one entity stored in 
>different tables' with triggers. But this discussion is not about a RDBMS 
>";-)
>
>As long as the relations you propose have a direction ('kills') it makes 
>sense to stored them as 'first' and 'second' somewhere. But when the 
>direction is symetrical ('is like') this implementation does not feel 
>right. Of course it is possible in Python to make a class around it, but 
>still if a piece of code wants to find all related objects it has to 
>search both the 'first' and the 'second' field.
>
>That sounds less generic than it could be in my opinion.
>  
>

In any case it is the responsibility of the application to define its
ontology. The relation engine shouldn't make any assumptions in that area.

if the relation is symmetrical, there are 2 relations:

    A is like B

means:

   A resembles B

and

   B resembles A    ( or A __ is resembled by __ B )

which you can express as a compound predicate:

    is_like = CompoundPredicate(Predicate('_ resembles _', '_ is
resembled by _'))

and do a query with:

    relations.search(predicate=is_like, first=A)

to get all the B:s in relation with A independently of the position.


Then most of the relations do have a direction ( __ has author __, __
was modified by __,  ...)

/JM