Implement Collection PHP Service

[ruebot]

Convenience operations for pcdm:Collections in Fedora 4.

Endpoint: http://localhost:8080/islandora/collection/

Actions:

• POST http://localhost:8080/islandora/collection/?tx={tx_id}
  • Creates a pcdm:Collection in Fedora 4.
  • Respects all headers the Fedora 4 API respects.
  • Adds the appropriate indirect containers to manage the pcdm:hasMember relationship and its inverse.
  • Optional transaction id will ensure the resources are created within said transaction.

PCDMize the paradigm

See also #105

[ruebot]

Scope:

• Creating an indirect container
• Applying appropriate PCDM predicate
• Membership; adding, removing, migrating resources
• Refactoring to integrate/share code between microservices

[ruebot]

See: #139 Refactoring to integrate/share code between microservices
See: #135 Creating an indirect container

[ruebot]

Membership; adding, removing, migrating resources will be incoming soon from @DiegoPino

[ruebot]

See: #140

todo: membership

[daniel-dgi]

To do for membership:

• Add: Provide a route that accepts parent and child uuids, creates a proxy for the child, and adds it to the indirect container of the parent.
• Remove: Provide a route that accepts parent and child uuids, and removes any proxies for the child in the parents indirect container
• Migrate: Call add and remove within a transaction.

[whikloj]

Playing with this and came across some...issues. Need to bounce off someone.

Because the indirect container does not have a UUID, there is not a route in the ResourceService that can handle accepting a UUID and sub-path, converting the UUID to Fedora URI and appending the sub-path.

So I would have to add proxies to the members using Chullo direct. This is not horrible, but it is breaking the separation between CollectionService / ResourceService / Chullo.

Do we add a route to the ResourceService that allows for non-UUID marked Fedora Objects ala (hack attempt)

$app->post('/islandora/resource/{id}/subpath/{path}', function (Request $request, $id) use ($app) {
   $fedora_uri = $app['islandora.idToUri']($id) . "/" . ltrim($path, '/');
   ....

Or should we be adding UUIDs to everything and then work out a way to get the members indirect container UUID when given the pcdm:Collection's UUID?

This leads me to the second question, should we be querying to see if an object already has a proxyFor in the desired collection, to avoid creating duplicates. I'm guessing we can get away with something like

select ?proxy where { 
   ?proxy ore:proxyFor </pcdm/object> . 
   </pcdm/collection> pcdm:hasMember ?proxy .
}

But I could be misunderstanding the whole proxy thing.

[ruebot]

Wouldn't we only have two cases where we have an indirect container with non-UUID; members, and files?

/islandora/resource/{uuid}/members/
/islandora/resource/{uuid}/files/

[whikloj]

You are the PCDM master, so I defer to you.

We can define routes specifically using those two paths. But then we will need to design a failure in the case that the Fedora resource specified by the Uuid does not have the requested indirect container under it.

If that is what we are okay with, then I would build these routes in the ResourceService as they can be reused for pcdm:Object as well as pcdm:Collection

tagging @DiegoPino cause he might not be getting these.

[daniel-dgi]

We should never be allowing direct access to those containers. Internally, we'll do a 3-store query to find them.

The /members and /files routes are simply routes. Even though they line up 1:1 with the names of our containers, we are not exposing them directly. We should not be exposing any of this to the end user, and the API should hide all LDP specifics.

[whikloj]

OK, I am going to go ahead with making something like this in the ResourceService and use it in the CollectionService.

[ruebot]

Oh. That's good to know 😄

[daniel-dgi]

@whikloj don't be afraid to make a util class and inject it into the controller to do these sorts of things. that's what i'm hoping to show you folks with the collection service refactor i'm doing.

we have DI. we need to really take advantage of it. it's just tricky, becuase if you do it wrong things can be worse than just jamming everything into controllers.

we'll talk about it on Monday. i'll have something to show you then.

[DiegoPino]

@jared, sorry late, but

Because the indirect container does not have a UUID, there is not a route in the ResourceService that can handle accepting a UUID and sub-path, converting the UUID to Fedora URI and appending the sub-path.

Do you need a post or a put? Eitherway,
If you look at the resource routes, they handle the uuid to real path as a middleware rewriting,
so if you do this (bypassing the route, but calling the controller directly)
$app['islandora.resourcecontroller']->post($app, $subRequestPost, $somefullroute) you don't need to match the uuid/ child or whatever…with put different, but you can pass the child
Where $somefullroute is already the fedora4 route you want, which can be constructed using the same middleware (you have access to it) + your extra paths

does this make sense?

[DiegoPino]

@whikloj, as talked in Skype, one way could be (no need to make it this way, but the way i could think of)

• have a route in collection service that accepts two UUIDs as arguments (one for the collection, one for the object we want into it)
• add middleware that creates subrequests
  • make sure both uuid's are different
  • Calls a get resource route for the first UUID
  • (if return is ok continue)
  • Calls a get resource route for the object we want to add to the first one,
  • (if return is ok) take the first fedora path (which should be there in the subresponses) and append the /member path, replace uuid1 and uuid2 arguments with this paths
  • end of middleware
• main route:
  • create a proxy resource (via twig) with rdf pointing to the resources we got from the previous responses (arguments uuid1 and uuid2 which are now fedora paths)
  • call the controller method for post directly with the new fedorapath and the proxy rdf created before

[whikloj]

PRs for addition and deletion of collection proxies are handled in
#160
and
Islandora/chullo#37

[ruebot]

Resolved with 72d17f7