Request for use cases: same object being child of multiple compound objects

[Mark Jordan]

Islandorians,

In today's committers' call we discussed this ticket:

https://jira.duraspace.org/browse/ISLANDORA-1301

Consensus of those present was that we could allow a single object to be a child of more than one parent compound object, but before anyone does any work to address the issue, we would like to hear if any Islandora implementers can supply a use case for this feature. No one on the committers' call could think of one. Note that this issue does not apply to objects being in the multiple collections - this feature is currently supported and works as expected.

Please reply to the lists as soon as is convenient if you can supply a use case.

Mark

[Mark Leggott]

If I understand this properly I think there are potentially a whack of use cases where a child object could be part of more that one parent:

- an institution decides to allow alums to create or “curate” compound objects from collections of digitized material, 4 people from the Class of X all select a class photo as a child of their parent object;
- a research repository is accessible to grad students who are all using the same CSV file as a child to their respective conference paper citations;
- a manuscript page image is used a a child object for different transcripts created by students in a DH class.

That is a few - the key is once this capability exists, then the use cases would emerge.

Mark

> --
> For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
> ---
> You received this message because you are subscribed to the Google Groups "islandora" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/islandora.
> For more options, visit https://groups.google.com/d/optout.

[Mark Jordan]

Thanks Mark, I've linked to this thread from the issue.

Mark

---

[Diego Pino]

I checked, after the call, my repos and found we also have a similar use case (sorry for my silence during the call, completely forgot about those), we are sharing/reusing same image objects for different parent Biodiversity objects. A particular child image(a preserved specimen) is compound to an Ocurrence Darwin Core Class term object and also to an equivalent, similar but not the same, flat one (Simple darwin core). Also some researchers are using this functionality to make related papers being associated to occurrences, taxons, etc, the same paper may be child of different type of objects, it's a context question. So we actually have a need for this.   I think compound and collections should behave mostly the same way, it's just a different predicate/theming, but the differences are semantically not many.

Diego

[Giancarlo Birello]

From my point of view a compound object is something "inseparable" like postcard front and rear view while collection is a group of independent objects.

I think we have to pay attention to not approximate relationships to the only one of compound and collection because this can result in a lost of information. My thought is ontology relationships to preserve information about digital object is better than limit all to a couple of relation.

However, I agree with the possibility a child object could be part of more parents for the simple reason that Islandora is a powerful and really open architecture able to satisfy every kind of implementation.

Giancarlo

[Kilian Amrhein]

We use Islandora as an access system in our digital preservation infrastructure. There are two roles of people accessing it: Administrators (interested in data like contractID, data provider, deliveryID etc.) and the content users (interested in the descriptive information like creator, title, rights, etc. of i.e. an artwork). Needing to serve both these use cases, we came up using the compound sp as follows: 

For each content file (i.e. image, metadata-XML) we create a single child object, which then gets connected to two compound parents: an admin access and a content access object. The first mainly holds the administrative metadata in its DC, the second a descriptive DC. Users can access the parent objects depending on their (Drupal-)role. Content users would mostly see only the content objects in the collection view and Solr-results, whereas administrators would probably be able to access both. 

So I mainly did the following changes to the SP:

- While accessing the compound object, default behavior is to display the first child and not the actual compound parent. This has been changed to display the actual object the user clicked on in the collections view (probably one of the parents). However we still have a bug, where the children get displayed as well in the collections view, while the Solr results are correctly not displaying them.

- The "Manage parent" link links to the manage overlay of the administrative or content parent, depending on the role of the user.

- To be able to switch between the parents, there are again two use cases: Having opened a parent and having access rights to the other, a link is displayed accordingly in the Object Navigation Block ("Go to …"). Having opened a child, a link to one or both parents is displayed, depending on access rights. See here: https://github.com/kamrhein/islandora_solution_pack_compound/blob/7.x-1.4/islandora_compound_object.module#L655-696

For those interested, I will also give a talk on this at OR: https://www.conftool.com/or2015/index.php?page=browseSessions&form_session=54

This might be a very special use case with very specific adjustments, but is maybe still of use for the community or may serve as a base for generalization and addressing the ticket?

 

Cheers

Kilian

[patrick....@commonmediainc.com]

A use case presented to me today:

There is a content model for an author (a person/corporation) that has a number of datastreams (photo, metadata). A compound object for "paper" includes one or more authors. An author may have this relationship to many papers.

[Jared Whiklo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would suggest that this use case is probably better supported with
the entities solution pack then making compounds out of papers and
authors.

But running with this example, how would you expect to access the
parent "papers" from the child "authors", in both the case of multiple
parents and a single parent?

cheers,
jared

> -- For more information about using this group, please read our
> Listserv Guidelines:
> http://islandora.ca/content/welcome-islandora-listserv --- You
> received this message because you are subscribed to the Google
> Groups "islandora" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> islandora+...@googlegroups.com

> <mailto:islandora+...@googlegroups.com>. Visit this group
> at http://groups.google.com/group/islandora. To view this
> discussion on the web visit
> https://groups.google.com/d/msgid/islandora/0a2f678f-91f3-4607-966e-ad
c0b362edb4%40googlegroups.com
>
>
<https://groups.google.com/d/msgid/islandora/0a2f678f-91f3-4607-966e-adc
0b362edb4%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

- --
Jared Whiklo
jwh...@gmail.com
- --------------------------------------------------
You are validating my inherent mistrust of strangers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iEYEARECAAYFAlYD9oYACgkQqhIY384dF1a1XgCffNK9A8KMEn9k/wGyXxf9Ez8c
Jk8AoIuOBhor/8OKU94c6edOWzSqvLCD
=SRm8
-----END PGP SIGNATURE-----

[Diego Pino]

Hi Pat, if you are willing to experiment, i think this is a good case for my ontologies solution pack. Basically the compounding (current) relation is a generic way of relating objects but does not have the sufficient granularity to express deep tree - multiple with meaning- relations. So in that case a formal ontology based on named predicates makes a lot more sense. The solution pack has a way of displaying this relations using graphs, so people can discover deep nested relations in a "simple" (if such thing exist!) way. We can talk about this if you or any one else is interested.

Best

Diego

[patrick....@commonmediainc.com]

I haven't used the entities solution pack. Unless I'm missing something, it provides several useful content models, without providing any deeper functionality about how they relate to each other or to other objects. Is that right? 

Jared, it seems to me that Diego is proposing the ontologies solution pack as the answer to your question about accessing papers from authors. As usual, the problem with ontologies is that it always seems like overkill for a simple problem. But perhaps that's because I have not tried it out. Drupal is usually overkill too, but we use it anyway because it can handle any problem we can dream up. Perhaps we should look ontologies the same way.

[Jared Whiklo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I haven't used the entities solution pack or Diego's onotology
solution pack so I can't really give you much information on either.
It seems to me that the entities solution pack more closely mirrors
your use case. But you'd really need to try it out to see for sure.

My suggestion was more because the issue is around ISLANDORA-1301[1]
and whether there were other use cases for child objects of compounds
that have multiple parents.

If you would still like to use compounds for the paper <-> author
type. Can you give some thought to how the display of multiple parents
should appear when viewing a compound?

cheers,
jared

> <http://groups.google.com/group/islandora>. To view this

>> discussion on the web visit
>
> https://groups.google.com/d/msgid/islandora/0a2f678f-91f3-4607-966e-ad
>
> c0b362edb4%40googlegroups.com
> <https://groups.google.com/d/msgid/islandora/0a2f678f-91f3-4607-966e-a
dc0b362edb4%40googlegroups.com>
>
>
>
>

> <https://groups.google.com/d/msgid/islandora/0a2f678f-91f3-4607-966e-a
dc
>
> 0b362edb4%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/islandora/0a2f678f-91f3-4607-966e-a
dc0b362edb4%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
>> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> -- For more information about using this group, please read our
> Listserv Guidelines:
> http://islandora.ca/content/welcome-islandora-listserv --- You
> received this message because you are subscribed to the Google
> Groups "islandora" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> islandora+...@googlegroups.com
> <mailto:islandora+...@googlegroups.com>. Visit this group
> at http://groups.google.com/group/islandora. To view this
> discussion on the web visit

> https://groups.google.com/d/msgid/islandora/14a85045-85d7-4e9a-ada4-b7
33a457aaa8%40googlegroups.com
>
>
<https://groups.google.com/d/msgid/islandora/14a85045-85d7-4e9a-ada4-b73
3a457aaa8%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
- --
Jared Whiklo
jwh...@gmail.com
- --------------------------------------------------

Half the people you know are below average.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iEYEARECAAYFAlYEJtYACgkQqhIY384dF1bBEwCfblRxTvQMDOU4KFq0BliC832Q
FNEAoMmuqq1P45AAmhWCRWuGLHCg5lIH
=YstW
-----END PGP SIGNATURE-----

[Joanne Parandjuk]

I haven't actually created this use case but I have thought about it.

Parent Object 1= Archival Envelope
Child 1 photograph 1.tiff
Child 2 letter

Parent Object 2= Photo Album Cover
Child 1 photograph 1.tiff
Child 2 photograph 2.tiff
Child 3 photograph 3.tiff
Child 4 photograph 4.tiff

Parent Object 3= postcard
Child 1 photograph 1.tiff
Child 2 back.tff

[Rosemary Le Faive]

I agree with Giancarlo that the best use of a compound is for multi-part inseparable objects (e.g. side 1/side 2, tape 1, ..., tape N, etc.).

The two main use cases for multiparental compound objects seem to me to fall into two categories:

- curated collections (like individual users creating a "course pack" by selecting specific objects from the repo)

- clustering related objects (like grouping authors with their works, or objects which are different iterations of each other). 

These should really be solved using collections and relationships/ontologies respectively. But not everyone is able to (or should) do the coding or Views wizardry needed to make these objects display on each others' pages.

In my view, the Compound Object SP is a shortcut so that users with basic skills can set up those Omeka-like displays that everyone wants.

We need something like this, and until there's a better system built-in, I think we should continue using Compound. My vote is that we adapt it for the case of multiple parents.