Allow direct discovery of container URIs?

[azaroth42]

Currently, you can find the containers associated with an Object or Collection by looking in ldp:contains. You can then look at the ldp:hasMemberRelation to determine the use of the container.

SELECT ?container WHERE { <> ldp:contains ?x . ?x ldp:hasMemberRelation pcdm:hasMember . }

This requires that the containers be contained by the Object/Collection, which is an LDP (or protocol, if you will) requirement. If the containers were to be hierarchically separated from the object (e.g. they were not contained) then this pattern would no longer work. Is it valuable to decouple these?

[escowles]

It might be valuable to decouple these and model the relationship of the Object/Collection to the order/membership mechanisms. When I was looking at how IIIF Presentation API would map to PCDM, I thought some of the IIIF entities mapped to PCDM orders, so making some of that more explicit in the model could help make mappings like that clearer.

[awoods]

@azaroth42, to be clear, is this issue focused on being able to discover the Direct and/or Indirect containers that have an ldp:hasMemberRelation relationship to a given resource?

[azaroth42]

This was from the conversation on Monday at HydraConnect about being able to discover which container to use to create members vs relatedObjects vs files. With a full on SPARQL endpoint you could query for hasMemberRelation and membershipResource ... but that's pretty far from the follow-your-nose HATEOAS approach.

Thus there could be:

<object1> pcdm:hasMembershipContainer <object1/members/> .

Triple added to allow clients to just follow that link to the container.

[awoods]

Would pcdm:hasMembershipContainer be designed to only point to containers that have the ldp:hasMemberRelation of pcdm:hasMember? Or is this issue broader in scope: How to discover containers that have any ldp:membershipResource relationship to the target resource?

[tpendragon]

This feels like an issue I'd want to keep out of PCDM - I'm inclined to make a hard barrier between "how do I assert these triples" (which has an unbound number of solutions based on the implementation of PCDM - LDP being only one of them) and "these are the triples that need to exist to navigate the structure" (which is PCDM, in my mind).

I'm scared if we start trying to model how to create the triples with the memberships rather than just stating "these triples need to be there" that we'll end up with more corner cases than we can handle.

[daniel-dgi]

Is it safe to assume that there will always be a triple store or document database somewhere for when you need to make queries? Keeping everything you need to work with contained in the RDF without having to resort to an external service seems prudent to me.

I'm running into this issue now trying to make a library for working with PCDM. I've wound up requesting the embedded resources from Fedora and am searching the graph manually. I can't say I'm thrilled about it, but it does seem like the most agnostic solution to the problem. See: https://github.com/daniel-dgi/porkpie/blob/master/src/Porkpie.php#L229-L271

But after reading the comment from @terrellt , is LDP even a safe thing to assume?

[tpendragon]

@daniel-dgi I don't think it is in a general case - if I publish a static resource via nginx/apache with PCDM triples, that's PCDM, no? My understanding is that we're trying to solve interoperable structural metadata, and not APIs for asserting structure.

For your library, I'd expect some way to separate "I have a PCDM graph, now do stuff" from "go get a graph."

[azaroth42]

I don't think we should assume either LDP or a triplestore as necessary components for compliant PCDM implementations. However this issue and proposal /does/ assume LDP ... otherwise there would be no need to discover the container, as there wouldn't /be/ a container :)

[daniel-dgi]

Yeah, it's tough. You guys are playing at a different level than me. You're modeling while making no assumptions whatsoever (totally appropriate). I'm sorting out an implementation, which leaves me in the unfortunate position of judiciously choosing as few assumptions as possible. It's on me to make sure I don't push implementation leakages through to the model.

So despite it's usefulness, as @azaroth42 has stated, we can't expose this without exposing LDP. In reality, I'll just have a few different implementations in my library: a sensible default using Fedora's LDP capabilities and one or more where you can query the RDF if you have an external service.

So... close won't fix?

[azaroth42]

How about a protocol level solution for the protocol level problem ... being link headers on the responses from the PCDM Collection and Objects pointing to their containers? If so ... we could discuss in a new issue and close this one (about the ontology) with wontfix?

[daniel-dgi]

Wow, @azaroth42. That would be amazing. 👍 to that, and 👍 to close wontfix this issue.

[awoods]

👍 @azaroth42, to closing this issue and moving to Link header discussion.
Pre-discussion: I assume this would be a non-standard, custom Link header?

[azaroth42]

Closing, wontfix.