Object's parent relationship don't seem to persist?

[dmoses]

I created a collection object. I then created a basic image object and associated it with that new collection object. While I can select the collection in the metadata form, the selection doesn't seem to get applied in the object. If I go back in and try to manually add it ... it appears in the record ... but then disappears. I need to test this some more ... just noting it as an issue to follow up on. dm

[dmoses]

Confirmed this is a bug. The hasParent path can be changed in the form and it initially appears in the node's metadata, but when the node is refreshed in the browser the hasParent path reverts to http://localhost:8080/fcrepo/rest/

[ruebot]

tagging @Islandora-Labs/7-x-2-x-committers

[DiegoPino]

@dmoses, i will look at this.

[dmoses]

@DiegoPino I think what we might need here is for the pcdm:memberOf property to be written to the child object?

[ruebot]

@dmoses agreed. We actually need to go back and make everything PCDM compliant. We only kinda did it in our rush for Islandoracon.

tags @daniel-dgi

[DiegoPino]

@dmoses, i wish it would be that way. But currently inverse/direct relations(automatic creation) are being exclusive at Fedora's level LDP i think. We can do it at drupal of course. Will re-check, maybe i'm understanding stuff the wrong way.

[jpeak5]

Having only looked into this from the Drupal side, it seems like the wiring between the form and its handler is a tad off.

For new nodes, we alter the form to include a drop-down of existing collections, giving it the name 'parent_collection'. I'm learning (both Drupal and Islandora) here, so let me know where I'm way off, but it seems like this arbitrary(?) field name is in part responsible for the parent uuid value getting lost on save.

FWIW, here is the submit handler inislandora_basic_image.module:

function islandora_basic_image_add_parent_uuid(array $form, array &$form_state) {
  $node = $form_state['node'];
  $node->parent_collection = "";
  if (isset($form_state['parent_collection']['#value'])) {
    $node->parent_collection = $form_state['parent_collection']['#value'];
  }
}

Seems like it should assign $form_state['parent_collection']['#value'] to something like $node->field_fedora_has_parent rather than $node->parent_collection before handing off to the core drupal processes, right ?

[DiegoPino]

@jpeak5, I would have to do some dpm() to $form_state to see what is there (not looking right now at the code). But probably you are in the right direction. But looks like a simple thing, probably the most complex part will be the pcdm mapping (and not that complex also i hope). Thanks!.

[DiegoPino]

@dmoses, to expand the LDP notion of this: @daniel-dgi was making this questions at fedora-tech. https://groups.google.com/forum/#!topic/fedora-tech/1Zk8L59KcRk

[ruebot]

@dmoses @DiegoPino @jpeak5 -- looking at this closer now. This is the intended behaviour. All objects live under Fedora root in Fedora 4. The membership relationship is asserted on the collection object. If you look at the collection object, it should have a something like this:

pcdm:hasMember: 
http://localhost:8080/fcrepo/rest/01/52/9c/d7/01529cd7-c169-4bd1-a6df-3671998f3f2c

It is also represented in this diagram:

Does that make sense?

@daniel-dgi @acoburn please correct me if I am wrong.

[daniel-dgi]

@dmo @ruebot It's optional (but probably a good idea) to use both pcdm:hasMember on the collection and pcdm:memberOf (its inverse) on the child object.

[ruebot]

@daniel-dgi agreed. We need to implement the inverse.

[ruebot]

http://pcdm.org/2015/09/28/models

[ruebot]

Should we close this, and create another issue to implement pcdm:memberOf?

[daniel-dgi]

@ruebot Yes, definitely a ticket. Posted to the LDP list about the best way to implement it. Not sure i understand the directions i've been given. Maybe @DiegoPino or @acoburn can help me out?

See https://lists.w3.org/Archives/Public/public-ldp/2015Oct/0001.html and its response: https://lists.w3.org/Archives/Public/public-ldp/2015Nov/0000.html

[daniel-dgi]

HAHAHAHAHAHA. I just tagged dmo instead of @dmoses !!!!

[ruebot]

Closing this based on discussion, and creation of #105.