[deepamehta-users] Address Model in DM Webclient

Torsten Ziegler torsten at ziegi.de
Wed Feb 25 18:45:43 CET 2015

Hi Juergen,

i think part of this functionality has to go into the
deepamehta core to be available for all kinds
of topics and relations.


Am 25.02.2015 um 17:59 schrieb Juergen Neumann:
> Hi Torsten,
> I agree with you. Maybe we can think of a way of implementing this into
> the webclient as you suggested.
> Very kindly,
> JuergeN
> Am Montag, den 23.02.2015, 14:28 +0100 schrieb Torsten Ziegler:
>> Hi Jörg,
>> I am still listening the deepametha lists and
>> want to reply to this last posts as I thought a lot
>> about the semantic side effects (as you also did)
>> I thinke the very object (here the address entry)
>> should know about its semantic status.
>> An address - imho - is a fixed object that does not
>> change (if the street/city does not get eradicated,
>> even then it should stay the same for history tracking).
>> But a person may move to another address.
>> So I would prefer to share one address for all
>> people living in one place.
>> And while editing the address of a person
>> the reference to the old address should automatically
>> break and the newly edited address again should be
>> system wide shared among all persons living there.
>> This would mean each object (like address etc.) needs
>> to know about its behaviour in case of an editing process.
>> Just my thoughts,
>> Torsten
>> Am 23.02.2015 um 14:11 schrieb Jörg Richter:
>>> Hi JuergeN,
>>> oh, that's cool you have implemented an address equality check already!
>>> Yes, for your import-via-REST use case you can change that association (between the Address Entry and Address types) to Aggregation Definition. It will work. Just put the ref_id: or ref_uri: prefix in your POST request to refer to an existing Address topic. The Address topics will be shared between several Persons then.
>>> Also editing a Person in the detail panel will work. Just be aware of semantic side-effects: editing one person's address will change the address for all involved persons as well. (Possibly you have to reload to clear the browser cache in order to see the effect.) In case you want deliberately avoid that side effect you can delete the Aggregation (between the Address Entry and the Address) before editing a particular Person. In the detail panel you can then enter a new independent Address for that Person.
>>> Cheers,
>>> Jörg
>>> On Feb 21, 2015, at 19:03, Juergen Neumann wrote:
>>>> Hi Jörg,
>>>> I understand the general apsect of the specific issue. In my case I want
>>>> to create new persons via the REST API. I have implemented a check if an
>>>> address topic alread exists. If so, I want to reassign this very address
>>>> to the newly created person.
>>>> So my question is, if I change the assoc type from composition def to
>>>> aggregation def for the entire address, will it break anyting (in the
>>>> webclient) or can I just try it, to see how it goes ...
>>>> Thx,
>>>> JuergeN
>> -- 
>> Torsten Ziegler www.ziegi.de www.chin-med.de

Torsten Ziegler www.ziegi.de www.chin-med.de

More information about the users mailing list