OK, got it. The URI's are:
ref_uri:dm4.contacts.mobile
ref_uri:dm4.contacts.home_phone
ref_uri:dm4.contacts.home_fax
ref_uri:dm4.contacts.work_phone
ref_uri:dm4.contacts.work_fax
Cheers,
JuergeN
Am Mittwoch, den 18.02.2015, 23:20 +0100 schrieb 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: [
> > "[email protected]",
> > "[email protected]"
> > ],
> > 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
> > > [email protected]
> > > http://lists.deepamehta.de/mailman/listinfo/devel-lists.deepamehta.de
> >
>
>
--
devel mailing list
[email protected]
http://lists.deepamehta.de/mailman/listinfo/devel-lists.deepamehta.de
