AdministrativeSets and ldp:contains

[escowles]

Currently, AdministrativeSet is defined as a subset of ldp:Container and uses ldp:contains to link to Objects and Collections it contains. This works fine when the expected repository structure is to use have AdministrativeSets be top-level containers with their Objects and Collections directly inside them:

/set1/object1
/set1/collection1
/set2/object2
/set2/collection2

But if you structure your repository with all resources at the top level (which I think we decided was a good practice to avoid having to change identifiers if a resource changed ownership from one AdministrativeSet to another):

/collection1
/collection2
/object1
/object2
/set1
/set2

Then the Objects and Collections aren't contained by the AdministrativeSet. And Fedora will not let you create the triple </set1> ldp:contains </object1>, since ldp:contains is a server-managed predicate.

Should we be using a different property for belonging to an AdministrativeSet?

[daniel-dgi]

That sounds appropriate if we want to be able to move things around and keep the 'everything at the top level' scenario going.

pcdm:administrates? I'm sure there's a better predicate name than that if others agree on this approach.

[awoods]

@escowles, although pcdm:AdministrativeSet sub-classes ldp:Container does that mean that there is an expectation that pcdm:AdministrativeSets use the ldp:contains predicate to define the set's membership?

[escowles]

@awoods I think we might want to change both the predicate and superclass. If the Object/Collections are directly contained by the AdministrativeSet, then ldp:Container and ldp:contains are appropriate. But if the Collections/Objects are not necessarily contained, then the predicate should change, and there might be a better superclass too.

[kestlund]

@escowles have we not just turned this into another ore:Aggregation, then, but put our own arbitrary limits on this particular aggregation?

:+1: to not having to change identifiers when moving objects between administrative sets

[jcoyne]

:+1: to not changing identifiers when moving objects between administrative sets.

Could we use info:fedora/fedora-system:def/relations-external#hasCollectionMember for this?

[escowles]

Maybe just dcterms:hasPart/dcterms:isPartOf? I would think Objects/Collections are logically contained by the AdminSet.

[jpstroop]

@escowles FWIW, I had the same thought during the call.

[jcoyne]

@escowles Yeah, dcterms:isPartOf/:hasPart would do nicely and it has a deferenceable url.

[escowles]

If AdminSet doesn't subclass ldp:Container, should it subclass something else? ore:Aggregation like @kestlund was suggesting? Or nothing?

[DiegoPino]

@escowles, is there an example diagram (or rdf) of an AdminSet "in action"? I know it's a newbie question, but i could not find an example. I'm :+1: to not changing identifiers when moving objects between administrative sets. I also like the idea of moving pcdm:AdministrativeSet out of the tree and making them independent, (even reusable, the reason i would like to see an Adminset in action) and not making them "contain", in terms of LPD, other objects under it's administration.

[jcoyne]

@escowles from my perspective, extending nothing is preferable. If we write the isPartOf assertions on the members (hasPart is inferred), we have the most efficient solution in terms of LDP requests. I wouldn't be broken hearted if we decided to make them extend ore:Aggregation and use an IndirectContainer either. That would leave the door open for ordering down the road. You just know that someone wants that. :neutral_face:

[escowles]

@DiegoPino: I think the basic linkage of AdminSets, Collections and Objects should be:

</set1> a pcdm:AdministrativeSet; dcterms:title "Admin Set #1" .

</col1> a pcdm:Collection; dcterms:title "Collection #1";
  dcterms:isPartOf </set1>; pcdm:hasMember </obj1> .

<obj1> a pcdm:Object; dcterms:title "Object #1"; dcterms:isPartOf </set1> .

I have heard only vague descriptions of how people use Admin Sets. At UCSD, we attached access control triples to them that set the default access control policy for the objects they included. We also indexed the Admin Set an object was in, and used that as a facet in Blacklight.

[DiegoPino]

@escowles, thank you very much for your example.

Seeing this i confirm it could be good practice to move it then out of the hierarchy as you correctly suggested initially.

I think the subclassing is directly related to what are you going to put there, do you also have agreed on what properties will be standard to have interoperability? if you need/could need the ability to nest some stuff inside or basic descriptive properties in some domain like dcterms would be sufficient, knowing this could help define this.

But i personally don't like dcterms:isPartOf because if i understand correctly you are "appending administrative" notions, but it's not there is no "belonging" to a whole there or the other way.

Different meanings, you are just extending the notion of a resource to an administrative domain that could even be reused by multiple other objects.

[escowles]

@DiegoPino: No, there isn't any agreement on what properties would be attached to an Admin Set, or how they would be treated. I have heard them mentioned, but I'm only familiar with UCSD's usage of them. There has not been any substantial discussion of them in PCDM, other than noting that they are sometimes used.

Do you have any alternative suggestions for what predicate to use to link Objects to Admin Sets?

[kestlund]

I think I'm still leaning back to yet another ore:aggregation and ore:aggregates, because of the flexibility that it might give us in the long-run.

With such little "there there" with admin sets, I wonder if we should try to get a bit more info. about how people are using them. Access controls and ownership are the only real use cases I've heard. Other use cases are typically moved to collections when interrogated.

[azaroth42]

Given the desire to have admin sets outside of the URI path hierarchy (to avoid changing URIs of things when they move admin sets), and the lack of strong requirements, could we just recommend using Collections for the mean time until those requirements emerge?

[escowles]

I'm fine with taking a wait-and-see approach. At some point, if we don't have a clearer notion of how AdminSets should work, we should remove them. But I know there are several institutions that use some form of AdminSet, so I don't want to give up on them yet.

[DiegoPino]

@escowles i did not respond on your question because i was (and still are) investigating a good approach on this. You are right, we can't give up on AdminSet, but we should discuss to what extend we are going to use this, without reinventing the wheel to make it interoperable. E.g, access control. What if we need to apply this differently to multiple aggregates inside an object. (like exposing derivatives but securing sources). How do we define, when using users and roles, where/how are those enforced? (maybe pointing to a service that allows for authentication for that particular user).

I think this is a open discussion, but it's good we have a talk about that and see what others are doing. Lastly: keep it as simple as possible, could even mean just attaching properties directly to each resource.