CollectionService should allow you to get a collection.

[whikloj]

There is no GET method in the CollectionService so
curl -i http://localhost:8282/islandora/collection/f07c0d38-8290-4c2d-877c-233dfce374e1

throws a HUGE error, while
curl -i http://localhost:8282/islandora/resource/f07c0d38-8290-4c2d-877c-233dfce374e1

works fine.

Question is should /islandora/collection ONLY retrieve pcdm:Collection objects?

[DiegoPino]

yeah, collections in this scope are only pcdm:Collection, for the rest resourceService is fine. I would go for that @whikloj, and for members? is this get only for the base resource?

[whikloj]

@DiegoPino this is the question, because currently I just pass the UUID onto the ResourceService and it gets anything.

So you can retrieve a pcdm:Object by using it's UUID with this endpoint.

So either, we can leave it the way it is or

1. take the UUID and check to see if it exists (by using the islandora.idToUri function)
2. Check if the object has a rdf:type of pcdm:Collection
3. Return if 1 & 2 are true

Problem is what error do we return if there is an object, but it is not a Collection?

Maybe that is just adding an extra roadblock for a simple GET request?

As for members, that is part of the Collection in that they have pcdm:hasMember properties.

In my opinion, if you want information about the indirect container, then we need to add a UUID to it (which we discussed doing) and do a separate GET for that UUID to get a list of its proxy objects.

[ruebot]

How about 405 Method Not Allowed?

[whikloj]

I'm going to add this to Wednesday's call, as I would like to talk this out. I'm not sure what the expectation is...also I'm not sure how much time we want to spend in here right now.

But let's just agree to hold this PR and discuss that various GET routes then.

[ruebot]

@whikloj added to agenda 😄

[DiegoPino]

@whikloj 👍 for In my opinion, if you want information about the indirect container, then we need to add a UUID
The GET question is complex. Basically having a different service for each type of returned graph is an overkill right?
So in my opinion: UUID onto the ResourceService for anything.
GET in collection to get base object and children's UUID or Path? (now you will have to use a pager for them…)
So complex man

[whikloj]

Ok, so to confirm:

Any endpoint that supports GET to will return the resource for the UUID passed to it.

So a GET to /islandora/collection or /islandora/resource with the same UUID will get the same results.

[DiegoPino]

@whikloj i missed that call maybe. GET to /islandora/collection should get you the members or a not allowed, if we are lazy, but in my opinion, that is the reason why have the resource one, why duplicate functionality?

[whikloj]

@DiegoPino So a GET to /islandora/collection should return the members indirect container, the proxy objects, or the pcdm:hasMember references?

[DiegoPino]

@whikloj without further thinking, which i will do today, i would suggest pcdm:hasMember
Assuming all this stuff is for pcdm

[DiegoPino]

Also, if we where some future aware people with lots of free time, we should get(in a future) all indirect containers that point back to the collection, get their membership predicates and use that to discern what to get... but for now 👍 on PCDM static awareness

[whikloj]

So...assuming I got it right, the consensus is that a GET on a pcdm:Collection from the CollectionService will get the pcdm:hasMember properties off the collection and return the UUIDs for all of them.

There is an outstanding issue in Fedora 4 where resources that are updated by an indirect container do not fire an event when they are updated. I am told it will be fixed when FCREPO-1742 and FCREPO-1498 are resolved.