[deepamehta-devel] Get complete data from dm4.contacts.person

[Juergen Neumann]

Hi Jörg,

so far everything works fine. Only that I cannot add any another phone
label than ref_uri:dm4.contacts.mobile. When I try e.g.
ref_uri:dm4.contacts.home or ref_uri:dm4.contacts.work, then it does not
work. Any ideas?

Thx

Juergen

Am Mittwoch, den 18.02.2015, 19:35 +0100 schrieb Jörg Richter:
> Hi Juergen,
> 
> to create a Person topic via REST:
> 
>     curl -X POST -H 'Authorization: Basic YWRtaW46' -H 'Cookie: dm4_workspace_id=2301' -H 'Content-Type: application/json' -d '{
>         type_uri: "dm4.contacts.person",
>         childs: {
>             dm4.contacts.person_name: {
>                 dm4.contacts.first_name: "Lucy",
>                 dm4.contacts.last_name: "Suchman"
>             },
>             dm4.contacts.email_address: [
>                 "lucy at suchman.com",
>                 "lucy at home.com"
>             ],
>             dm4.contacts.phone_entry: [
>                 {
>                     type_uri: "dm4.contacts.phone_entry",
>                     childs: {
>                         dm4.contacts.phone_label: "ref_uri:dm4.contacts.mobile",
>                         dm4.contacts.phone_number: "0177 123456789"
>                     }
>                 }
>             ]
>         }
>     }' http://localhost:8080/core/topic
> 
> While not all the Person's child topics are set in this example (no Address for example) this demonstrates some crucial aspects. You should be able to transfer these to the other Person parts.
> 
> You create a Person by POSTing a topic JSON representation to /core/topic.
> 
> Note that the JSON is less verbose than the JSON you're GETing, e.g. you must specify no "id", "uri", "assoc" properties, and no "value" property for composite topics (as this is computed).
> 
> You see, when the child is modeled as cardinality "many" you have to specify an JSON array, that is [ ... ]
> 
> Another important thing is when the child is modeled via Aggregation Definition. In this case you have 2 options: a) create a NEW child, or b) refer to an EXISTING child. This is relevant e.g. with the Phone Label. Here you want refer to the existing phone label "mobile". You can do the referral by-ID or by-URI. That is you must know the ID or the URI of the topic you want refer to. You must prefix the value with "ref_id:" or "ref_uri:" respectively. For the Phone Label you use by-URI because its easier (the Phone Label URIs are fixed whereas the ID differ on each installation).
> IMPORTANT: if you don't use one of these prefixes the other case applies: you'll create a NEW child, that is you would CREATE another Phone Label (additionally to the 5 existing ones).
> 
> So, potentially you have to deal with referral and these prefixes always when Aggregation Definitions are involved in the underlying model. That applies e.g. also to all the Address childs (Street, Postal Code, City, Country). All these are defined via aggregation. So, when you actually want REUSE e.g. the City topic "Berlin" for all the Berlin addresses, you must refer to that very Berlin topic (as said, either by ID or by URI).
> 
> One more thing: when you specify the child topics in a JSON topic, you can choose between 2 formats: 1) the "simplified" format, or 2) the "canonic" format.
> 
> Simplified format:
> 
>     childs: {
>         type.uri1: "my value",
>         type.uri2: "my value"
>     }	
> 
> Canonic format:
> 
>     childs: {
>         type.uri1: {
>              id: 1234.
>              uri: "my.uri",
>              type_uri: "type.uri"
>              value: "my value"
>              childs: {
>                  ...
>              }
>         },
>         type.uri2: {
>             ...
>         }
>     }
> 
> That is with the simplified format you specify just the child topic's values. That is sufficient e.g. when you want create a bunch of simple child topics with just the (payload) values set.
> In contrast when you want give the new childs topics not only the (payload) values but dedicated URIs as well (or when when the childs are not simple but composite) you have to choose the canonic format. Here you can specify complete topic representations possibly with all of the 5 canonic topic properties (id, uri, type_uri, value, childs).
> 
> In a topic JSON representation you are free to mix both formats, just like in the Person example above.
> 
> Tell me if you need any more help.
> 
> Cheers,
> Jörg
> 
> 
> On Feb 18, 2015, at 17:31, Juergen Neumann wrote:
> 
> > Hi Jörg et al.,
> > 
> > how do I get|write all data from or to an dm4.contacts.person instance,
> > including multiple adresses and phone numbers. I did not yet manage to
> > get the complete composite through the REST call.
> > 
> > Can you help me please.
> > 
> > Thx
> > 
> > Juergen
> > 
> > -- 
> > devel mailing list
> > devel at lists.deepamehta.de
> > http://lists.deepamehta.de/mailman/listinfo/devel-lists.deepamehta.de
>