Objects can have related objects.

[jcoyne]

No description provided.

[jcoyne]

What predicate should be used for this?

[jcoyne]

Should this be a container or just an association?

[escowles]

It should be a container called "related" and use the predicate ore:aggregates.

[jcoyne]

@escowles I'm not sure that's possible. The object IS and aggregation. It would have to aggregate related, and members all together.

[elrayle]

There was a discussion about a potential implementation of this at a lower level activefedora-aggregations - issue #11, but it was decided that it would be implemented at the PCDM level.

Summary

Background:

Groups of things in a Collection are...

• Collection pcdm:hasMember Collection
• Collection pcdm:hasMember Object
• Collection ore:aggregates Object (related object)

Groups of things in an Object are...

• Object pcdm:hasMember Object
• Object ore:aggregates Object (related object)
• Object pcdm:hasFile File
• Object pcdm:hasRelatedFile File (related file)

NOTE: hasFile and hasRelatedFile are not aggregations and therefore are not covered under the Proposed Solution. See #19

Proposed Solution:

Collections and Objects

Collections and objects will be in a single aggregation with predicate pcdm:hasMember. This is consistent with the current implementation.

Defined by:

aggregates :members, :predicate => RDFVocabularies::PCDMTerms.hasMember, :class_name => "ActiveFedora::Base"

NOTE: The same approach will be used for Object pcdm:hasMember Object

Related Objects

The Collection object will have a property with predicate pcdm:hasRelatedObjects which will point to a pcdm:Object that serves as an ORE:aggregation of the related objects.

Defined by:

property :relatedObjects, predicate: RDFVocabularies::PCDMTerms.hasRelatedObjects

NOTE: The predicate is plural because it is a container for the related objects, not the related object itself.

NOTE: The same approach will be used for Object's related objects.

[tpendragon]

property :relatedObjects, predicate: RDFVocabularies::PCDMTerms.hasRelatedObjects, class_name: 'ActiveFedora::Base'

should work and do what you expect.

I think the objects pointed to by relatedObjects can just be a Hydra::Work too, which makes me happy.

[jcoyne]

@terrellt that doesn't seem like a solution, because it will not have order.

[tpendragon]

@terrellt that doesn't seem like a solution, because it will not have order.

class_name 'PCDM::Work' or whatever the class is would be more correct.

[azaroth42]

The proposed solution is exactly what the model currently says, so 👍 to the proposed solution :D

[elrayle]

@jcoyne My understanding was that the benefits of having a separate object aggregate the relatedObjects was...

• ability to request only related objects (as opposed to getting both related objects and members together)
• easier management of separate predicates
• and ability to apply order to the aggregation of related objects

Hydra::Works::GenericWork and GenericFile are both PCDM::Object so unless the code for Hydra::Works::GenericWork and/or GenericFile limits the aiblity of one or both of these to be used as related objects, then they would be able to serve as related objects. That said, it doesn't mean that Sufia will surface this ability through its UI.

[tpendragon]

@azaroth42 Do we need to mint a new predicate for "hasRelatedObjects" (the plural) within PCDM?

[escowles]

I thought the model said each pcdm:Object should have a container (not a pcdm:Object) that contained proxies for related objects, called {object}/related/, and that the property used to link to the related objects would be ore:aggregates.

[escowles]

BTW, I'm working from this Google doc:

https://docs.google.com/document/d/1RI8aX8XQEk-30-Ht-DaPF5nz_VtI1-eqxUuDvF3nhv0/edit#

Is this still the latest LDP-implementation-of-PCDM spec?

[tpendragon]

@escowles That works except in the case that you want to order related objects separately from member objects.

[azaroth42]

Use case for ordered related objects? Use cases to date have not required
ordering there at all.
On May 6, 2015 5:19 PM, "Trey Terrell" [email protected] wrote:

@escowles https://github.com/escowles That works except in the case
that you want to order related objects separately from member objects.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[tpendragon]

@azaroth42 I can make some up, but who knows if they'd be used (Collection Documents Page 1). Right now it's more of an implementation detail - if we use ore:aggregates then there's no reason those documents shouldn't be able to be ordered, but right now there's a tight couple between member updating and ordering.

[escowles]

Is the issue that there can only be one iana:first/iana:last on a pcdm:Object, so we can only have one ordered set? Do we need to make the files/, members/, and related/ containers ore:Aggregations? Then each could have its own ordering?

[tpendragon]

@escowles Files aren't aggregated, but yes - that's the issue. We could make members/ and related/ ore:aggregations, but that's counter-PCDM and we'd have to figure out the relations

[azaroth42]

Until someone has a valid use case that is shared by two or more
institutions, I propose that this is not an issue for a baseline shared
model, which is what PCDM is.
On May 6, 2015 6:54 PM, "Trey Terrell" [email protected] wrote:

@escowles https://github.com/escowles Files aren't aggregated, but yes

• that's the issue. We could make members/ and related/ ore:aggregations,
  but that's counter-PCDM and we'd have to figure out the relations

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[escowles]

@azaroth42, that's fine with me. So for now we can say that the members/ container is ordered, and all of the others are unordered.

[azaroth42]

+1. Is able to be ordered.
On May 6, 2015 7:46 PM, "Esmé Cowles" [email protected] wrote:

@azaroth42 https://github.com/azaroth42, that's fine with me. So for
now we can say that the members/ container is ordered, and all of the
others are unordered.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[escowles]

Yes, important correction: members/ is able to be ordered, the others are unordered.

[jcoyne]

I think this ticket is actually invalid. hasRelatedObject is not part of PCDM.
See examples:
https://wiki.duraspace.org/display/FF/PCDM+Examples

[elrayle]

I agree that the document currently does not describe the proposed solution. If the proposed solution is acceptable, then the application profile should be updated to reflect this.

[escowles]

The examples do include a related file:

https://wiki.duraspace.org/display/FF/PCDM+Examples#PCDMExamples-Multi-PageTextshowingcontainedandrelatedfiles,memberandaggregatedobjects

The mods.xml file is a related file, linked to with ore:aggregates.

[jcoyne]

@escowles this ticket is for related objects, not related files. Related files is #62

[tpendragon]

So proposals:

1. Use ore:aggregates to link objects which are related. DO NOT order. Don't necessarily use indirect containers (why would you? Don't need proxies)
2. Use some property which doesn't imply ordering is allowed.
3. Use a predicate to point to a pcdm:object which encapsulates a collection's related objects, and hasMember from there.

[escowles]

@jcoyne I've updated the diagram to have a related object (donor agreement) linked with ore:aggregates: https://wiki.duraspace.org/display/FF/PCDM+Examples#PCDMExamples-Multi-PageTextshowingcontainedandrelatedfiles,memberandaggregatedobjects