What even IS Islandora 8?

[R Le Faive]

Having spent a little while poking in Islandora 8, as part of UPEI's CANARIE-funded Research Data Management project, I don't know what an "Islandora object" is anymore. 

And while I'm speaking for myself, the words below represent a (long) collaboration with Charlie Tillay, with feedback from Danny Lamb. 

In Islandora 7 we had a clear concept of an "Islandora object". It was stored in Fedora, not Drupal, and you could interface with it at [drupal url]/islandora/object/[PID]. Built into the Fedora 3 object model was the concept of being "one discrete thing" that had datastreams, each containing binaries or metadata. Built into the Islandora interface was the concept that the files-and-metadata were "a unit" and could be managed as one. It was also clear that Drupal content was "just Drupal CMS stuff", and NOT part of our preservation repository. And you could tell this without a CS degree or an understanding of the underlying architecture.

As I understand it now, the Islandora 8 model of an object is: A Node (being of a designated content type and containing metadata in Drupal Fields) and one-or-more Media (attached to the node). Some bits of metadata, to better model the hierarchical structure of MODS as an RDF graph, are now stored on other Nodes or Terms that are related to the first. If everything's configured right, your files live in Fedora and the metadata gets transformed to RDF which is also sent to Fedora. And derivatives happen. And all the other stuff you expect.

However, 8 was deliberately built to make every word of that optional:

Does being "an islandora object" mean being a specific content type? (no)

Defaults comes with a "Repository Object" content type, which is configured to behave as an Islandora object (i.e. do "Islandora Stuff". Get sent to Fedora. Do derivatives. ... )

But the point of "Islandora Defaults" was to be a starting point, a model to allow anyone to make their own Islandora content types and configure them appropriately. So being "a node of type Repository Object" is sufficient, but not necessary. And there's no checkbox to tick when configuring my new content type that says "[✔️] this is an Islandora content type". Functionally, it can be any content type, as long as it's configured to behave in a certain way.

Does being "an islandora object" mean behaving in a certain way? (haha. no)

Every bit of what we've considered behaviour of Islandora Objects can now be configured separately - derivatives, FITS, bagit, Matomo, search, which Media can be attached - and again, all are optional. So no single behaviour determines that a content type "is Islandora". Kind of like trying to define what physical property makes something "a chair", the function and affordances are more important to our definition (in our case, the affordance of preservation), rather than any individual feature or behaviour. Islandora objects don't have to get TNs or FITS derivatives, etc. But we think of Islandora as the middleware to put things, through Drupal, for preservation, in Fedora.

What about being in Fedora? (no)

Here's the part that's a little scary. We have even made Fedora optional. Hypothetically, someone could set up Islandora to use a different repository backend, by altering/replacing the "Index node in Fedora" Action and creating an appropriate Flysystem setup that points to an alternate storage layer and probably some other stuff. Someone could even set up Islandora to just use Drupal (but, please, don't.) We've done really well in not hardcoding any behaviours of Islandora Objects. But that leads to this existential angst.

Does being "an Islandora object" mean an object that can have Media? (no?)

Here's a little tidbit that I realized I had forgotten. The Media tab on Nodes was put there by Islandora. In plain Drupal, Media are like cats and own themselves. But Islandora puts a field_media_of on the Media types (Audio, Image, File, and Video). Thus these media types appear when adding a Media to a Node, and can "belong to" nodes. The field_media_of (along with field_media_use, as per Danny) allows a Media to function as an Islandora Media, and out of the box in the playbook, all Media types are Islandora Media types. But not all media types in Drupal have to be, and strictly-core-Drupal Medias are not.

Also, the "Media Tab". The Islandora Core Features causes the Media tab to appear on all nodes (including Articles and Basic Pages) and out of the box, Drupal will let you add media to nodes of any type. Therefore when I see a Media tab, I don't know for sure that this node is an Islandora node.

Does being "an Islandora object" mean an object that can have/be Members? (no?)

The pcdm:hasMember property is part of the PCDM object model, and the Islandora Defaults module puts a field_member_of on the Islandora Repository type so they can be members of other nodes. According to Danny, field_member_of is required to be on a content type for that content type to be Islandora (of course, it isn't a required field - Islandora/PCDM "Objects" don't have to be members of anything.) 

Islandora (module) also creates a "Members" tab/view, that displays on nodes and shows their members. But this tab shows up (confusingly, as above) on all nodes including Articles and Basic Pages.

So based on the interface, I can't say whether any given content type, even Article, is actually Non-Islandora, or just a degenerate case of an Islandora node, simplified within the limits of its definition, so that it ceases to make sense as an Islandora object.

And here's where it becomes a problem: When I look at Islandora 8, I just see a bunch of "stuff". Drupal doesn't know the difference between Nodes and Islandora Nodes, or Media and Islandora Media, so my Repository Items and RDM Datasets are all mixed in with Articles and Pages. While I know (because I set the system up) that RDM Datasets and Repository Items and maybe a few more "are islandora," I really wish that the interface communicated to my users (e.g. technicians, grad students, etc) that "these content types are special - they're not just Drupal they're Islandora. Use these if you want your content to be "in the repository". I want to clearly distinguish preservation objects from ephemeral web content.

Because I (and I'm sure other librarians/archivists) care very much to know what nodes and media and stuff "is islandora" and is "in Fedora". I want to be able to answer the question "how many islandora objects are in my repository?" If certain behaviours are supposed to happen (like going into Fedora), I want the interface to confirm that they happened (and if they didn't, help me so I can fix whatever prevented them). It's really scary, given the asynchronicity and the number of moving pieces between Drupal and Fedora, that I might wrongly assume something is in Fedora when it isn't.

And I wish that I could say "all my important information is in Fedora". I want to know that I have to do "preservation stuff" to the Fedora infrastructure and that given a catastrophic failure, I could rebuild from a backup of the repo. But I don't know what all's in my Fedora, given the situation described above, and we haven't really ensured there is (though we've hinted that there should be) a process for restoring an Islandora from a Fedora. I mean, the reverse mapping would be painful, sure, but at least include the forward mapping, defined as it is in YML!. As it is, we put stuff in Fedora but don't read from it and don't trust it to be complete. This seems like a lot of work setting up the Fedora stack for very little gain. Drupal is a CMS, not a DAM, and it feels ill-advised to use it as our canonical repo copy. I'm also a liiiiitle bit worried by Drupal's frequent security updates and the number of Drupal sites I've seen hacked.

TL;DR: Islandora should be be more Repo, less CMS.

So, suggestions:

- I'd like the UI to really distinguish "islandora" stuff from "just drupal".

- I'd like the UI to provide more transparency as to what is in Fedora (and particularly, what is supposed to be, but isn't).

- I'd like Fedora to contain enough to rebuild my Islandora.

According to Danny, the presence of the following fields makes a thing Islandora:

Nodes:

- field_member_of

- field_model

Media:

- field_media_of

- field_media_use

Taxonomy:

- field_external_uri

Can we make a... flag? semaphore? functions like "is_node_islandora($content_type)" that can help with UI sugar to explain to users what's what, while ONLY letting other modules interface with it using Contexts or Views or otherwise user-configurable workflows? Danny expressed some rightful concern that this could lead to baking in behaviour (yes, it'd be tempting, I am lazy) rather than going with our paradigm of "everything should be configurable."

I mean, to start with, can there be a Context or otherwise configurable setting so that we can turn off the Media and Members tabs on non-Islandora nodes?

That's my piece. The void of knowledge has been gazing back at me for a while now.

Cheers and we'll chat more, I'm sure, at the CLAW call.

[Diego Pino]

Hey Rosie, can i cite you/this post in another group? This is a good read for anyone working with D8 in a Metadata scenario. Let me know if you are Ok/not-ok. Thanks!'

Diego

[R Le Faive]

Hey Diego,

I'm glad you think it's useful! But I don't know what it can good it can do (at this point) for someone outside our community. It's very focused on the specific configurability (a good thing!) that is built into Islandora.

I realize it is dangerous to say in public that I'm concerned about Islandora-as-preservation, because in the wrong hands this could be weaponized against us. I do not want that. I posted this among us to spur some discussion and let the brilliant talented minds on this forum come together to address this. But I think this warrants a longer-form discussion than Slack affords, which is why this wasn't posted there. 

If you want to discuss the idea that a CMS does not a DAM make, this tweet articulates it succinctly. 

I would urge discretion. If you know people who can help us find a solution, by all means please invite them in. 

[Jared Whiklo]

https://metro.org/news/Archipelago-Beta-Launch

On 2019-08-28 7:55 a.m., R Le Faive wrote:
> Hey Diego,
>
> I'm glad you think it's useful! But I don't know what it can good it can
> do (at this point) for someone outside our community. It's very focused
> on the specific configurability (a good thing!) that is built into
> Islandora.
>
> I realize it is dangerous to say in public that I'm concerned about
> Islandora-as-preservation, because in the wrong hands this could be

> weaponized against us. I do not want that. I posted this among /us/ to

> spur some discussion and let the brilliant talented minds on this forum
> come together to address this. But I think this warrants a longer-form
> discussion than Slack affords, which is why this wasn't posted there. 
>
> If you want to discuss the idea that a CMS does not a DAM make, this

> tweet <https://twitter.com/ablwr/status/1163821186691870720> articulates

> it succinctly. 
>
> I would urge discretion. If you know people who can help us find a
> solution, by all means please invite them in. 
>

> --
> 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>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/islandora/073efbee-c63e-4147-a496-913cb84bc69b%40googlegroups.com
> <https://groups.google.com/d/msgid/islandora/073efbee-c63e-4147-a496-913cb84bc69b%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Jared Whiklo
Pronouns: he/him/his
jwh...@gmail.com
--------------------------------------------------
Not one shred of evidence supports the notion that life is serious.

[Nate Hill]

This blog post might be interesting for folks in this thread as well. 

http://blog.apotelesm.info/2019/08/the-island-and-archipelago.html?m=1

Nate

To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/88c024a7-136d-625a-94a6-14f66f4023d4%40gmail.com.

--

Nate Hill

Executive Director

Metropolitan New York Library Council

metro.org

917-375-0332

[Nate Hill]

I’m away on vacation and won’t be terribly responsive, but I would be thrilled to come back to a thread full of further ways of defining the CMS vs DAMS issue. After Ashley tweeted, I was sure to get access to that document so that I could add our unique and distinctly different repository project to the list. Indeed we are also using Drupal 8, albeit differently than Islandora, to manage our project so there definitely is some overlap in the usefulness of the topic you started here, Rosie.

Nate

[Mark Jordan]

Hi Rosie, and everyone else who has engaged in this thread so far,

I totally agree that the Media and Members of tabs showing up on all nodes is confusing UX. I would love to see this resolved for the next release (there is an issue for it but it didn't make it into 1.0). Even if it takes hacking those tabs out of sight with CSS, I think we should get rid of them on non-Islandora nodes.

I'm glad you brought up the Islandora-as-DAMS issue. My position is that Islandora can "do" digital assets management (and I think we're equating DAMS and digital preservation here, which I don't agree with but that's OK) as well as anything else, and that even bespoke, specialized systems like Archivematica (open source) and Preservica (proprietary) don't fulfill their DAMS/preservation mandate if their implementation doesn't have broad and deep institutional support. "Doing" DAMS/digital preservation is not a problem solved exclusively by software, although software supports that activity. It's more of an organizational problem.

I also think that we as a community have been distracted by Fedora's role in our ecosystem, particularly in Islandora 8. As with Archivematica and Preservica, turning on Fedora and putting your stuff in it doesn't mean you're doing DAMS/preservation. If Fedora is not part of a well articulated set of institutional policies and processes designed to achieve specific preservation goals and outcomes, and doesn't support those policies and processes, Fedora is not enabling preservation any more than Microsoft Edge is. If Fedora adds some specific preservation value to your DAMS, you should be taking advantage of it; if it doesn't, or you can't articulate what that value is, don't use it, it's just another piece of software you need to secure and upgrade. Personally, I think that Fedora 6's OCFL is one of those features that you probably want to take advantage of if you claim you are doing digital preservation, and that feature alone justifies using it in the Islandora stack.

I like to look at Islandora 7's and 8's preservation functionality (specifically, fixity auditing and export in a trusted packaging format [Bags], but there are features as well) through the lens of how they can support an institution's DAMS/preservation processes and desired outcomes. If my institution doesn't have an explicit preservation policy that articulates its desired outcomes, just turning on Islandora's fixity checking and Bagging doesn't buy me preservation. But if those features enable me to deliver on our stated preservation goals, turning them on and integrating them into our overall preservation processes does definitely help get us preservation.

These comments are a bit of a braindump in prep for the "Preservation capabilities of Islandora 8" workshop I'll be giving at the conference. During that workshop I will ask participants to get their hands on some of Islandora's preservation features and play with them, but only as a catalyst to help them start imagining how those features enable a broader, process-driven approach to preservation.

Mark

---

From: isla...@googlegroups.com <isla...@googlegroups.com> on behalf of R Le Faive <lef...@gmail.com>
Sent: Wednesday, August 28, 2019 5:55 AM
To: islandora
Subject: [islandora] Re: What even IS Islandora 8?

 

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/073efbee-c63e-4147-a496-913cb84bc69b%40googlegroups.com.

[Bethany Seeger]

You've really nailed something I've been thinking about and concerned about for a while, even as we embark on moving into Islandora 7, with the intention of getting to Islandora 8.  Essentially, and especially with a changed and optional relationship to fedora, how do I recover if the system dies?  Right now, I understand one can rebuild Islandora 7 from fedora, but if there's no central knowledge base in Islandora 8, how do I fix things if they break?  

Folks will need a very clear sense of what their repository is for - access or preservation -- and if it's preservation, then I want everything important (binaries,metadata, relationships) in "something" (like fedora) so that if things die, I know it's somewhere safe and presumable I've backed it up to preservation standards. 

I would love to talk more about this and explore options.  At the same time I'm thinking about this, I especially like the solid integration that Islandora 8 has with drupal - it's clean, though I don't have the experience with it that you do, Rosie, so it's interesting to hear how it can be confusing to identify what is an islandora object.  Looking forward to learning more. 

Best,

Bethany

On Tuesday, August 27, 2019 at 4:36:57 PM UTC-4, R Le Faive wrote:

[Peter Murray]

In April 2006 (oof! ages ago!), I wrote a blog post:

    Why Fedora? Because You Don’t Need Fedora

    https://dltj.org/article/why-fedora-because-you-dont-need-fedora/

The crux of the post was this:

If your Fedora system blows up -- software glitch, disk failure, or heaven forbid a logic bomb -- you can restore the entire thing by simply reading files off the disk.  Yep -- that's right.  That large and complex software package only optimizes access to the objects.

I've been watching FEDORA-beyond-version-3 and Islandora 8, and I don't think it is as straight forward as the FEDORA-3-and-earlier setup.  Has someone written an equivalent document about how one restores an Islandora 8 system from a FEDORA backup?  Is that even possible?

Peter

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/fd74934b-fcf6-404e-806b-113b55d43c60%40googlegroups.com.

[Jared Whiklo]

Hi Rosie,

This is a dense read, and I'm sure I'll miss something so bear with me.
Comments inline, below.

On 2019-08-27 3:36 p.m., R Le Faive wrote:
> Having spent a little while poking in Islandora 8, as part of UPEI's
> CANARIE-funded Research Data Management project, I don't know what an
> "Islandora object" is anymore. 
>
> And while I'm speaking for myself, the words below represent a (long)
> collaboration with Charlie Tillay, with feedback from Danny Lamb. 
>
> In Islandora 7 we had a clear concept of an "Islandora object". It was
> stored in Fedora, not Drupal, and you could interface with it at [drupal

> url]/*islandora/object/[PID]*. Built into the Fedora 3 object model was

> the concept of being "one discrete thing" that had datastreams, each
> containing binaries or metadata. Built into the Islandora interface was
> the concept that the files-and-metadata were "a unit" and could be
> managed as one. It was also clear that Drupal content was "just Drupal
> CMS stuff", and NOT part of our preservation repository. And you could
> tell this without a CS degree or an understanding of the underlying
> architecture.

I feel like this is comfort with the thing we know. When you say

> Built into the Fedora 3 object model was the concept of being "one
> discrete thing" that had datastreams, each containing binaries or
> metadata.

Except if it was a book, or newspaper, or serial. All repository objects
are constructs of various bits. We just became comfortable with how
Fedora 3 worked over years of trial and error and so we could visualize
it easier. Fedora (4,5,6) or any LDP server still allows the same object
model to be built. But it also allows for more flexibility.

> It was also clear that Drupal content was "just Drupal
> CMS stuff", and NOT part of our preservation repository.

So in this point do you mean if you blew away Drupal then your
repository was a headless Fedora 3 instance? Because yes that is true,
as it would be if you blew away your Drupal in an Islandora 8 instance.

The point is to have all your preservation objects and metadata in your
repository. The difference is to not have to call out to that repository
just to reveal a display copy.

>
> As I understand it now, the Islandora 8 model of an object is: A Node
> (being of a designated content type and containing metadata in Drupal
> Fields) and one-or-more Media (attached to the node). Some bits of
> metadata, to better model the hierarchical structure of MODS as an RDF
> graph, are now stored on other Nodes or Terms that are related to the
> first. If everything's configured right, your files live in Fedora and
> the metadata gets transformed to RDF which is also sent to Fedora. And
> derivatives happen. And all the other stuff you expect.
>
> However, 8 was deliberately built to make every word of that optional:
>

> *Does being "an islandora object" mean being a specific content type? (no)*

> Defaults comes with a "Repository Object" content type, which is
> configured to behave as an Islandora object (i.e. do "Islandora Stuff".
> Get sent to Fedora. Do derivatives. ... )
> But the point of "Islandora Defaults" was to be a starting point, a
> model to allow anyone to make their own Islandora content types and
> configure them appropriately. So being "a node of type Repository
> Object" is sufficient, but not necessary. And there's no checkbox to
> tick when configuring my new content type that says "[✔️] this is an
> Islandora content type". Functionally, it can be any content type, as
> long as it's configured to behave in a certain way.
>

> *Does being "an islandora object" mean behaving in a certain way? (haha.
> no)*

> Every bit of what we've considered behaviour of Islandora Objects can
> now be configured separately - derivatives, FITS, bagit, Matomo, search,
> which Media can be attached - and again, all are optional. So no single

> behaviour determines that a content type "/is/ Islandora". Kind of like

> trying to define what physical property makes something "a chair

> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.226.6060&rep=rep1&type=pdf>",

> the function and affordances are more important to our definition (in

> our case, /the affordance of preservation/), rather than any individual
> feature or behaviour. Islandora objects don't /have to/ get TNs or FITS

> derivatives, etc. But we think of Islandora as the middleware to put
> things, through Drupal, for preservation, in Fedora.
>

> *What about being in Fedora? (no)*

> Here's the part that's a little scary. We have even made Fedora
> optional. Hypothetically, someone could set up Islandora to use a
> different repository backend, by altering/replacing the "Index node in
> Fedora" Action and creating an appropriate Flysystem setup that points
> to an alternate storage layer and probably some other stuff. Someone
> could even set up Islandora to just use Drupal (but, please, don't.)

> We've done really well in /not/ hardcoding any behaviours of Islandora

> Objects. But that leads to this existential angst.
>

> *Does being "an Islandora object" mean an object that can have Media? (no?)*
> Here's a little tidbit that I realized I had forgotten. *The Media tab
> on Nodes was put there by Islandora.*In plain Drupal, Media are like

> cats and own themselves. But Islandora puts afield_media_of

> <https://github.com/Islandora-CLAW/islandora/search?q=field_name%3A+field_media_of&unscoped_q=field_name%3A+field_media_of>on

> the Media types (Audio, Image, File, and Video). Thus these media types
> appear when adding a Media to a Node, and can "belong to" nodes. The

> field_media_of(along with field_media_use, as per Danny) allows a Media

> to function as an Islandora Media, and out of the box in the playbook,
> all Media types are Islandora Media types. But not all media types in

> Drupal have to be, and strictly-core-Drupal Medias are /not/.

> Also, the "Media Tab". The Islandora Core Features causes the Media tab
> to appear on all nodes (including Articles and Basic Pages) and out of
> the box, Drupal will let you add media to nodes of any type. Therefore
> when I see a Media tab, I don't know for sure that this node is an
> Islandora node.
>

> *Does being "an Islandora object" mean an object that can have/be
> Members? (no?)*
> The pcdm:hasMemberproperty is part of the PCDM object model, and the
> Islandora Defaults module puts a field_member_ofon the Islandora

> Repository type so they can be members of other nodes. According to

> Danny, field_member_ofis required to be on a content type for that
> content type to be Islandora (of course, it isn't a /required/ field -

> Islandora/PCDM "Objects" don't have to be members of anything.) 
> Islandora (module) also creates a "Members" tab/view, that displays on
> nodes and shows their members. But this tab shows up (confusingly, as
> above) on all nodes including Articles and Basic Pages.
>

So the above does (IMHO) accurately state the flexibility of the
architecture. Maybe the problem is that while people say they want
freedom, they don't feel free until they hit a fence.

These are things that you can alter if you have a use-case to do so.

Maybe most won't... but in Islandora 7.x you didn't have a choice. We
side-loaded and crammed functionality into what there was.

Now there are lots of options and that can be frightening/confusing.

>
> So based on the interface, I can't say whether any given content type,

> even Article, is /actually/ Non-Islandora, or just a degenerate
> <https://en.wikipedia.org/wiki/Degeneracy_(mathematics)>case of an

> Islandora node, simplified within the limits of its definition, so that
> it ceases to make sense as an Islandora object.
>

So to use the default provided "Repository Object" as an example. This
where things become yours to alter.

I have no scholarly publications in my repository. I have pictures,
audio and video, some compounds, pdfs and newspapers.

So I "could" stick all the fields on "Repository Object" and put all my
"things" in there.

But we use PBCore for our audio/video objects instead of MODS. Maybe
"uofm_audio_video"

So I'll want a type for those that has different field mappings.

I have some large image pictures of Art objects that we contemplated
describing with VRA Core instead of MODS.

But we didn't because MODS was the default and already setup and easy to
use (read: No new XML Form Builder form).

Now I think maybe "Art Object" could be separate. Let's say
"uofm_art_object"

Probably the rest of the newspapers and large images (and compounds of
large images) will go in a single "type" (maybe even Repository Object).

So I have defined 3 Islandora content types. Things made out of and
lined to those content types are my "Islandora objects".

>
> And here's where it becomes a problem: When I look at Islandora 8, I
> just see a bunch of "stuff". Drupal doesn't know the difference between
> Nodes and Islandora Nodes, or Media and Islandora Media, so my
> Repository Items and RDM Datasets are all mixed in with Articles and

> Pages. While I /know/(because I set the system up) that RDM Datasets and

> Repository Items and maybe a few more "are islandora," I really wish
> that the interface communicated to my users (e.g. technicians, grad

> students, etc) that "/these/ content types are special - they're not
> just Drupal they're /Islandora. /Use /these/ if you want your content to

> be "in the repository". I want to clearly distinguish preservation
> objects from ephemeral web content.

Here you say

> Drupal doesn't know the difference between Nodes and Islandora Nodes,
> or Media and Islandora Media, so my Repository Items and RDM Datasets
> are all mixed in with Articles and Pages

Yes, they are. But they are different "content types".

So if I am displaying a page and I want all my "uofm_audio_video" to
show with a specific look/feel. I can tell it is an "Islandora object"
because above I defined that "content type" to hold my PB Core fields.

That "type" (uofm_audio_video) is part of the object and I can do a
whole host of things using that. Article is not one of my "content
types" so things I create as an Article would be treated differently.

This is the same as Islandora 7.

The difference is that I can create a view that combines these two types
(the Islandora and non-Islandora) into a single display/browse/whatever

So it would be possible (maybe even easy) to add a "is_islandora" flag
to a content type.

Then when a technician is logged in and views/edits a node. You could
add a banner revealing it as such.


>
> Because /I /(and I'm sure other librarians/archivists) care very much to

> know what nodes and media and stuff "is islandora" and is "in Fedora". I
> want to be able to answer the question "how many islandora objects are
> in my repository?" If certain behaviours are supposed to happen (like
> going into Fedora), I want the interface to confirm that they happened
> (and if they didn't, help me so I can fix whatever prevented them). It's
> really scary, given the asynchronicity and the number of moving pieces
> between Drupal and Fedora, that I might wrongly assume something is in
> Fedora when it isn't.

Maybe using a "is_islandora" field on your special content types, or
some other simpler method.

>
> And I wish that I could say "all my important information is in Fedora".
> I want to know that I have to do "preservation stuff" to the Fedora
> infrastructure and that given a catastrophic failure, I could rebuild
> from a backup of the repo. But I don't know what all's in my Fedora,
> given the situation described above, and we haven't really ensured there
> is (though we've hinted that there should be) a process for restoring an
> Islandora from a Fedora. I mean, the reverse mapping would be painful,
> sure, but at least include the forward mapping, defined as it is in
> YML!. As it is, we put stuff in Fedora but don't read from it and don't
> trust it to be complete. This seems like a lot of work setting up the
> Fedora stack for very little gain. Drupal is a CMS, not a DAM, and it
> feels ill-advised to use it as our canonical repo copy. I'm also a
> liiiiitle bit worried by Drupal's frequent security updates and the
> number of Drupal sites I've seen hacked.

This to a large extent I agree with. I have worked on Fedora 4,5 for
years and have never used it. But I understand the ideas and theories
behind it and its goal as part of a preservation suite of tools.

I agree that more "checking" will need to be added to ensure that the
objects from the front-end are stored in the back end and that (by using
Recast or other tools) we mimic the structural relationships that exist
in Drupal to their Fedora clones.

I definitely want to see a way to rebuild a Drupal instance from a
Fedora. This seems like a no brainer. If Fedora is the preservation
store, then Drupal should be able to be blown away (or hacked) and rebuilt.

But to the point of Drupal's frequent security updates... that is (again
IMHO) not a bad thing.

This is all open source software, there will be bugs. Knowing the risks
means you can mitigate them.

But as the old saying goes "Ignorance is bliss", so not seeing security
updates does not mean there aren't any. Just you don't know.

>
> TL;DR: Islandora should be be more Repo, less CMS.
>
> So, suggestions:
> - I'd like the UI to really distinguish "islandora" stuff from "just
> drupal".
> - I'd like the UI to provide more transparency as to what is in Fedora
> (and particularly, what is supposed to be, but isn't).
> - I'd like Fedora to contain enough to rebuild my Islandora.
>

All great ideas and I hope we (as the Islandora community) can work
together towards achieving this and more.

>
> According to Danny, the presence of the following fields makes a thing
> Islandora:
> Nodes:
> - field_member_of
> - field_model
> Media:
> -field_media_of
> - field_media_use
> Taxonomy:
> - field_external_uri
>
> Can we make a... flag? semaphore? functions like
> "is_node_islandora($content_type)" that can help with UI sugar to
> explain to users what's what, while ONLY letting other modules interface
> with it using Contexts or Views or otherwise user-configurable
> workflows? Danny expressed some rightful concern that this could lead to
> baking in behaviour (yes, it'd be tempting, I am lazy) rather than going
> with our paradigm of "everything should be configurable."

Oops, so I stole your idea. But it is a good one and not hard to implement.

I see two ways to do this:

1. An actual field that as a repository admin I would add to content
types that I say are "Islandora"

2. A calculated field (like the Fedora URI one) that is based off the
existence of the above other fields. This is easier to the end user but
probably a little more brittle.

But that is a discussion we can have.

>
> I mean, to start with, can there be a Context or otherwise configurable
> setting so that we can turn off the Media and Members tabs on
> non-Islandora nodes?
>

Yes, we just need someone with the desire to spend the time, investigate
the options, do the work and submit a PR.

I know this can be done. But right now, I have no idea how. Maybe you
could be the person to solve this riddle.

>
> That's my piece. The void of knowledge has been gazing back at me for a
> while now.
>
> Cheers and we'll chat more, I'm sure, at the CLAW call.
>

I hope I got it all.

I'll admit I was frustrated when I initially read this, but I think I
understand your point of view. I also think this will become better as
we all spend more time working with both Islandora 8 and Drupal 8 and
expand our toolset for these issues.

cheers,
jared

--
Jared Whiklo
Pronouns: he/him/his
jwh...@gmail.com
--------------------------------------------------

I've learned that no matter how much I care, some people are just jackasses.

[Aaron Birkland]

Fedora 6 (unreleased, in planning/development) and its intended adoption of OCFL is a kind of course correction away from 4/5 to restore the principle of “restore the entire thing by simply reading files on disk”.  Irrespective of this, the desire for islandora rebuildability from a preservation repository seems to be a common theme in this thread, as well as perhaps a desire for more UI feedback as to the preservation status of an object and its parts. 

 

  -Aaron

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/ca79513b-a45a-4470-9638-c078e05d0ed9%40Spark.

[R Le Faive]

To Mark Jordan's points: Well taken, that DAM and Digital Preservation are not the same thing. I like the lens of preservation-as-institutional policy/practice/system, and look forward to your workshop. I think "doing" preservation is much more difficult to manage when Islandora-isms bleed into general Drupal, because those types of content are usually managed by (if they exist) different policies.

To Bethany: Yes, I think "ideally"  the Fedora in Islandora 8 at this moment should contain everything needed to back up. But because the Fedora system is no longer used for access ... as Jared points out, it seems silly to call to a repository to get a display copy ... but for access at all, we don't get the feedback that  proves our data is there. It should be, but I"m not one to trust. And as the community grows, I think creating such a knowledge base for disaster recovery would be very useful.

To Peter: Something something Modeshape, Fedora 6, OCFL. (oh, read Aaron's reply, he beat me to it.)

[Jared Whiklo]

I should also draw attention to the Fedora community. We as Islandora
talk a lot about Fedora but very few get involved to any degree.

There are calls each Thursday at 11:00 ET. The next is tomorrow.

https://wiki.duraspace.org/display/FF/2019-08-29+-+Fedora+Tech+Meeting

Much like the Islandora Committer calls are not just for committers, the
Fedora Tech call does not require or discuss only technical issues.
Lurkers welcome.

Additional there is an entire separate community around the Oxford
Common Filesystem Layout specification which is something good in its
own right but which is part of the persistence design for Fedora 6.

https://ocfl.io/#participate

cheers,
jared

On 2019-08-28 9:26 a.m., Peter Murray wrote:
> In April 2006 (oof! ages ago!), I wrote a blog post:
>
>     Why Fedora? Because You Don’t Need Fedora
>     https://dltj.org/article/why-fedora-because-you-dont-need-fedora/
>
> The crux of the post was this:
>

> /If your Fedora system blows up -- software glitch, disk failure, or

> heaven forbid a logic bomb -- you can restore the entire thing by simply
> reading files off the disk.  Yep -- that's right.  That large and

> complex software package only optimizes access to the objects./
> /
> /

>> at [drupal url]/*islandora/object/[PID]*. Built into the Fedora 3

>> object model was the concept of being "one discrete thing" that
>> had datastreams, each containing binaries or metadata. Built into
>> the Islandora interface was the concept that the
>> files-and-metadata were "a unit" and could be managed as one. It
>> was also clear that Drupal content was "just Drupal CMS stuff",
>> and NOT part of our preservation repository. And you could tell
>> this without a CS degree or an understanding of the underlying
>> architecture.
>>
>> As I understand it now, the Islandora 8 model of an object is: A
>> Node (being of a designated content type and containing metadata
>> in Drupal Fields) and one-or-more Media (attached to the node).
>> Some bits of metadata, to better model the hierarchical structure
>> of MODS as an RDF graph, are now stored on other Nodes or Terms
>> that are related to the first. If everything's configured right,
>> your files live in Fedora and the metadata gets transformed to RDF
>> which is also sent to Fedora. And derivatives happen. And all the
>> other stuff you expect.
>>
>> However, 8 was deliberately built to make every word of that optional:
>>

>> *Does being "an islandora object" mean being a specific content
>> type? (no)*

>> Defaults comes with a "Repository Object" content type, which is
>> configured to behave as an Islandora object (i.e. do "Islandora
>> Stuff". Get sent to Fedora. Do derivatives. ... )
>> But the point of "Islandora Defaults" was to be a starting point,
>> a model to allow anyone to make their own Islandora content types
>> and configure them appropriately. So being "a node of type
>> Repository Object" is sufficient, but not necessary. And there's
>> no checkbox to tick when configuring my new content type that says
>> "[✔️] this is an Islandora content type". Functionally, it can be
>> any content type, as long as it's configured to behave in a
>> certain way.
>>

>> *Does being "an islandora object" mean behaving in a certain way?
>> (haha. no)*

>> Every bit of what we've considered behaviour of Islandora Objects
>> can now be configured separately - derivatives, FITS, bagit,
>> Matomo, search, which Media can be attached - and again, all are
>> optional. So no single behaviour determines that a content type

>> "/is/ Islandora". Kind of like trying to define what physical

>> property makes something "a chair

>> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.226.6060&rep=rep1&type=pdf>",

>> the function and affordances are more important to our definition

>> (in our case, /the affordance of preservation/), rather than any
>> individual feature or behaviour. Islandora objects don't /have to/

>> get TNs or FITS derivatives, etc. But we think of Islandora as the
>> middleware to put things, through Drupal, for preservation, in Fedora.
>>

>> *What about being in Fedora? (no)*

>> Here's the part that's a little scary. We have even made Fedora
>> optional. Hypothetically, someone could set up Islandora to use a
>> different repository backend, by altering/replacing the "Index
>> node in Fedora" Action and creating an appropriate Flysystem setup
>> that points to an alternate storage layer and probably some other
>> stuff. Someone could even set up Islandora to just use Drupal

>> (but, please, don't.) We've done really well in /not/ hardcoding

>> any behaviours of Islandora Objects. But that leads to this
>> existential angst.
>>

>> *Does being "an Islandora object" mean an object that can have
>> Media? (no?)*
>> Here's a little tidbit that I realized I had forgotten. *The Media
>> tab on Nodes was put there by Islandora.* In plain Drupal, Media

>> are like cats and own themselves. But Islandora puts a
>> field_media_of

>> <https://github.com/Islandora-CLAW/islandora/search?q=field_name%3A+field_media_of&unscoped_q=field_name%3A+field_media_of>

>> on the Media types (Audio, Image, File, and Video). Thus these
>> media types appear when adding a Media to a Node, and can "belong
>> to" nodes. The field_media_of (along with field_media_use, as per
>> Danny) allows a Media to function as an Islandora Media, and out
>> of the box in the playbook, all Media types are Islandora Media
>> types. But not all media types in Drupal have to be, and

>> strictly-core-Drupal Medias are /not/.

>> Also, the "Media Tab". The Islandora Core Features causes the
>> Media tab to appear on all nodes (including Articles and Basic
>> Pages) and out of the box, Drupal will let you add media to nodes
>> of any type. Therefore when I see a Media tab, I don't know for
>> sure that this node is an Islandora node.
>>

>> *Does being "an Islandora object" mean an object that can have/be
>> Members? (no?)*

>> The pcdm:hasMember property is part of the PCDM object model, and
>> the Islandora Defaults module puts a field_member_of on the
>> Islandora Repository type so they can be members of other nodes.
>> According to Danny, field_member_of is required to be on a content
>> type for that content type to be Islandora (of course, it isn't a

>> /required/ field - Islandora/PCDM "Objects" don't have to be

>> members of anything.) 
>> Islandora (module) also creates a "Members" tab/view, that
>> displays on nodes and shows their members. But this tab shows up
>> (confusingly, as above) on all nodes including Articles and Basic
>> Pages.
>>
>>
>> So based on the interface, I can't say whether any given content

>> type, even Article, is /actually/ Non-Islandora, or just a
>> degenerate
>> <https://en.wikipedia.org/wiki/Degeneracy_(mathematics)> case of

>> an Islandora node, simplified within the limits of its definition,
>> so that it ceases to make sense as an Islandora object.
>>
>>
>> And here's where it becomes a problem: When I look at Islandora 8,
>> I just see a bunch of "stuff". Drupal doesn't know the difference
>> between Nodes and Islandora Nodes, or Media and Islandora Media,
>> so my Repository Items and RDM Datasets are all mixed in with

>> Articles and Pages. While I /know/ (because I set the system up)

>> that RDM Datasets and Repository Items and maybe a few more "are
>> islandora," I really wish that the interface communicated to my

>> users (e.g. technicians, grad students, etc) that "/these/ content
>> types are special - they're not just Drupal they're /Islandora./
>> Use /these/ if you want your content to be "in the repository". I

>> want to clearly distinguish preservation objects from ephemeral
>> web content.
>>

>> Because /I/ (and I'm sure other librarians/archivists) care very

>> <mailto:islandora+...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/islandora/fd74934b-fcf6-404e-806b-113b55d43c60%40googlegroups.com

>> <https://groups.google.com/d/msgid/islandora/fd74934b-fcf6-404e-806b-113b55d43c60%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/islandora/ca79513b-a45a-4470-9638-c078e05d0ed9%40Spark
> <https://groups.google.com/d/msgid/islandora/ca79513b-a45a-4470-9638-c078e05d0ed9%40Spark?utm_medium=email&utm_source=footer>.

--
Jared Whiklo
Pronouns: he/him/his
jwh...@gmail.com
--------------------------------------------------

I don't know what your problem is, but I'll bet it's hard to pronounce.

[Peter Murray]

Thanks, Aaron -- this is helpful context.

Peter

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/BY5PR01MB6083915A44317ACAAF5032A0A4A30%40BY5PR01MB6083.prod.exchangelabs.com.

[Mark Jordan]

Rosie, great point, by excluding Fedora from the access process, we can't really trust that our stuff is still there. I'd like to suggest that one of the secondary functions (benefits?) of periodic fixity auditing is that it demonstrates the files are where Fedora thinks they should be. I'm comfortable with that assurance (others may not be) so YYMV.

About backup, I'll comment that restoring a repository is more a function of ordinary IT-based backups and disaster recovery than it is of digital preservation, which should assure long (I'd argue very long) term access to content that spans any particular repository platform or major version of a given platform. But there are a lot of points of view about whether restoring a repo is part of preservation and I respect the point of view that it is (respect but don't subscribe to).

Mark

---

From: isla...@googlegroups.com <isla...@googlegroups.com> on behalf of R Le Faive <lef...@gmail.com>

Sent: Wednesday, August 28, 2019 7:47 AM
To: islandora

Subject: Re: [islandora] Re: What even IS Islandora 8?

To Mark Jordan's points: Well taken, that DAM and Digital Preservation are not the same thing. I like the lens of preservation-as-institutional policy/practice/system, and look forward to your workshop. I think "doing" preservation is much more difficult to manage when Islandora-isms bleed into general Drupal, because those types of content are usually managed by (if they exist) different policies.

To Bethany: Yes, I think "ideally"  the Fedora in Islandora 8 at this moment should contain everything needed to back up. But because the Fedora system is no longer used for access ... as Jared points out, it seems silly to call to a repository to get a display copy ... but for access at all, we don't get the feedback that  proves our data is there. It should be, but I"m not one to trust. And as the community grows, I think creating such a knowledge base for disaster recovery would be very useful.

To Peter: Something something Modeshape, Fedora 6, OCFL. (oh, read Aaron's reply, he beat me to it.)

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/75760c32-cd87-446b-920d-7129fbf340ff%40googlegroups.com.

[R Le Faive]

And to Jared: I think we got to the same place in the end, but I wanted to reply to your earlier points. Was dense; took a while to chew. :) .

Comfort with a thing we know shouldn't prevent us from adopting new things. Agree! But in Fedora 3, the interface exposed the object model (properties, datastreams, etc). In Islandora 8, the interface does not, and is in some cases misleading (yes, I'll attempt to crack that nut).

"Except if it's a book..." Oh GEEZ I know. I had a whole philosophical digression about whether an Islandora Object "means" a single file, or an intellectual entity that is represented by one or more files. It can be both. I agree we have gotten used to that inconsistency (and it's coming up in weird places in the MIG's mapping, but anyway...). But we built a HECK of a lot of interface sugar in 7 so that books could be read, and looked/felt like "books" not "collections". Again, whatever object model we have should be reflected in the interface's affordances. I'm a broken record. Ok, no more.

By "just drupal cms stuff", I mean: I treat Drupals and their content as disposable. I can blow away my Drupal as much as I want, then point a new one to the Fedora and configure namespaces and BLAM! My whole dang repository (the stuff i care about) is back. I cannot plug-and-play a new "head" in 8, there's going to be content migration to do. 

"The point is to have all your preservation objects and metadata in your repository". YES!!! This is the point that I'm trying to make! I can't tell whether or not I do, Karaf/Queues/Microservices/Fedora are a black box with almost no feedback! 

"not have to call out to the repository to reveal a display copy". Word.

"e.g. I have defined 3 islandora content types". Okay, but you-who-set-up-the-system know that they're Islandora. A user doesn't. I agree, all of us are going to have our own set of "what content models are islandora". We will probably even consider different content models to be Islandora in different contexts - for example, when asked "how many digital objects I have" different people might need to count titles (books) or files (pages).  But how does someone who didn't set up the system know which ones are in any way Islandora? If there is "islandora stuff" and "not islandora stuff" then the interface should communicate that... hey yeah what you said. :) 

"security updates... not a bad thing". TRUE! I should have worded it as... Drupal's a massive glaring target, as a victim of its own success as a great OS project, there are huge botnets making sure that any insecure Drupal on the WWW is now sending out spam email and who knows what else. Its popularity as a hacking target is a liability.

"few get involved to any degree"

Whelp. Called out, putting it in my calendar.

[Don Richards Jr]

I probably don't fully appreciate the issue but I wondered about the comment on rebuilding from Fedora. If all of the content that isn't hosted in Fedora can be exported by one command `$ drush config-export --destination `, where is the concern? We could set up a process to use Fedora to keep track of the Drupal export file(like any other file), this could keep the entire configuration within Fedora; this would be a simple process to import all the necessary configurations (fields, configs, files, etc) making the rebuild simple and self contained.

My concern is this seems to me like a small modification and not much to be seriously concerned about(because it's easy to overcome). What should I educate myself on so I can fully appreciate the complexity of this concern? It always worries me I don't understand the entirety of the problem when the issue seems too simple.

[R Le Faive]

Don, before reading Mark Jordan's posts, I would have said hey you're absolutely right. And I think I may be to blame by conflating preservation with ability to restore a working system given only a repo.

Preservation often wants the objects to be readable and trackable over the long term, and an export of a Drupal 8.6.3 (or whatever we're on today) won't accomplish that. 

[Don Richards Jr]

OK, I think I follow. But the security comment has me. Last year Drupal had a total of 8 CVEs the same number as everyone's favorite Python (most of which were way more severe), whereas Wordpress had a mind blowing number of 17. In a lot of the security circles I follow, Drupal is usually considered the most secure CMS with the most proactive security team. Now how you secure your site and what vulnerable modules you use is up to the developer. 

[Danny Lamb]

This is a great discussion.  I've added this thread plus the relevant tickets I could find / make to the Islandora 8 call agenda for an hour from now:  https://github.com/Islandora-CLAW/CLAW/wiki/August-28,-2019

It would be great if we could capture all of these proposed improvements / features so we can act on them.  Hope to see folks there.

On Aug 28 2019, at 12:51 pm, 'Don Richards Jr' via islandora <isla...@googlegroups.com> wrote:

OK, I think I follow. But the security comment has me. Last year Drupal had a total of 8 CVEs the same number as everyone's favorite Python (most of which were way more severe), whereas Wordpress had a mind blowing number of 17. In a lot of the security circles I follow, Drupal is usually considered the most secure CMS with the most proactive security team. Now how you secure your site and what vulnerable modules you use is up to the developer. 

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/05da0b22-c22a-43d0-8d0b-78ff4ee1b28e%40googlegroups.com.

[Michelle Janowiecki]

Hi all, 

I've recently begun to get familiar with Islandora 8's architecture in anticipation of a Dspace-->Islandora 8 switch, and I really appreciated Rosie's post on Islandora objects as I have some similar questions. I'm new to this community, so I may be missing obvious points, but I had some thoughts that may contribute to the conversation.

To build on Rosie's comments, I think the idea of an Islandora object is made even more ambiguous given the combination of similar entity/relationship vocabularies from Drupal, Islandora, and Fedora. The introduction to the user-documentation, for instance, states that "an object is a node" but it's unclear if it is a Drupal object, some sort of conceptual object, or an Islandora object. I don't think it would correspond to an Islandora object, as a node doesn't necessarily have a file ("media") attached to it. But there seems to a persistent idea throughout the documentation that a node is some type of object, and I think clarification would be helpful. For instance, In the "What's Different Between Islandora 1.x and Islandora CLAW," it states that objects in Fedora are now referred to as resources, and that these "resources are stored as nodes on the Drupal side of Islandora CLAW." But since everything in Fedora is a resource (binary files and RDF data), it doesn't seem to be the case that ALL resources are actually stored as nodes, since some Fedora resources would be stored as files within the Media wrapper--not as a node itself. So I think the old terminology of objects from Fedora, as well as some ambiguity about nodes themselves does make this really difficult to parse out.

I've actually been trying to make a diagram just of Drupal/Islandora 8 architecture (not going to promise any accuracy here given my status as a beginner), and think maybe some more sophisticated versions of E-R type diagrams could maybe provide some clarity to the community, especially if we could see how Fedora and Drupal concepts correspond.

I'm am really exciting though about learning more about this community and thank you again Rosie for your post! It had so many great points.

https://drive.google.com/file/d/1e4WvCiLHur2E0VnNDhHSv8Hkk9RQmypY/view?usp=sharing (here is my little diagram)

[Diego Pino]

Hi Rosie,

I wrote this piece last night inspired by your post and just published it. https://groups.google.com/d/msg/archipelago-commons/8fwdee0kcPA/zmHyevNKAAAJ

If you feel uncomfortable with me citing you there please let me know, i can edit it. But this group and our group are open spaces and i feel this discussion permeates into other communities as well. Similar discussions have happened in the past in this realm, so it should not surprise people following the project closely.

As said, i personally think your post goes beyond this particular community and that is good, communities overlap because the needs in the repository world are quite common  (and simple) and what a particular software brings to the table somehow defines the community or its evolution and the community does the same for the software, in a healthy balance, but sometimes there is not back and forth, so the community gets unidirectionality converged into one way of doing things. Drupal (and many other CMS) are already being adopted outside Islandora as solutions to aid in repository work, and this has been happening for a long time, so people in the Drupal4lib world will see common ground in your statements. 

The difference between a DAM and a CMS is something we (Metro, myself, people i talk to in dark corners) have been discussing and working around for a long time, its actually what drove us in a different direction. I also don't feel the discussion point is necessarily about Fedora and its very number of versions but more what we all expect from a Repository system and the notion (my notion) that we have been just adding layers to the same old cake (cake = expectations) when we have/had always the chance to give, through old and new ideas, the whole repository definition that works for our communities a new spin (or old.. all old is new when there is a new implementation i would say). Kinda like pruning a plant to keep it healthy. I say this personally and there is no critic here. Stating the fact that in (meta) data there is an attempt of preserving (not necessarily the whole digital preservation machinery), describing and sharing identities (History, stories). And that identity, or the ability to digitally express that permeates into architecture, workflows and code, bound to what your communities and the people you care about needs, can contribute but also demands. That mix allows you to decide how much of that concern you want to take charge of.

In our Archipelago case (and i will try to not cross post between both groups in the future), the definition/the difference is given by what we decided is the mayor concern for our folks: Metadata, plasticity, portability and re-store-ability in an as simple as possible (with our own limitations) definition. And that meant planning and coding for that in specific. Some people would say its data separation, others functional separation, others stubbornness,  i would say its also role/needs/origin/source/destination definition first and then finding the common ground amongst the users believing in your proposal to prove us/you right/wrong.

Anyway, thanks a lot for sharing this. Note: Similar discussion has happened since the beginning of Islandora 8, when (look back into the code) we had a custom entity type for fedora content in D8 and not nodes.

Diego Pino 

Metro.org

To unsubscribe from this group and stop receiving emails from it, send an email to isla...@googlegroups.com.

[Paul Cummins]

Working with Islandora 7 and Fedora 3 for a while plus following how Fedora=
 is developing, I can't imagine how to think of an Islandora 8 configuratio=
n, with all the extra applications and settings plus the drupal databases p=
lus the local authentication constraints plus the theme customizations and =
images would fit into an OCFL directory structure beside your (say) 1 milli=
on preserved objects.   Using fedora to do disk backup sounds kinda iffy, b=
ut so does depending on one person to keep their ansible repos up to date t=
o be able to install Islandora 8.    Is there any progress in getting insta=
llation instructions for Islandora 8?

Paul Cummins
UTK Digital Initiatives

On Tuesday, August 27, 2019 at 4:36:57 PM UTC-4, R Le Faive wrote:

[Nia Kathoni]

Good read indeed. One thing I could suggest if not too late in the process it would have been good to build inslandora objects as drupal custom content entities instead of node (https://www.drupal.org/docs/8/api/entity-api/introduction-to-entity-api-in-drupal-8). 

Nia

On Tuesday, August 27, 2019 at 4:36:57 PM UTC-4, R Le Faive wrote:

[Danny Lamb]

We went there, and pivoted away from it because it was death by 1000 cuts for us to recreate all the Node functionality that was lost with a custom content entity.  That is, however, still possible to do and is what I would suggest doing if you run into scaling issues because of too many fields.  Like nodes, all that has to be on your custom content entity are those two fields, which you could bake in as base fields.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/1b3ca0b0-07d5-4b99-8ab8-1dbd272e6b7d%40googlegroups.com.

[R Le Faive]

Thanks everyone for the engaging, interesting, and over-time discussion on the CLAW call today. If you missed it, there's no minutes (impossible task) but some discussion was recorded in Slack. 

Point is, there are going to be a number (a handful, maybe) of tickets in the works to address some of the things outlined above: the distinction of "islandora" stuff vs "drupal" stuff; more transparency of expected behaviours, more transparency of whether expected tasks actually completed, and (perhaps) a fuller concept of what "an object" looks like in Fedora. Simultaneously,  "a definition of an islandora object" that librarians and other non-tech people can learn and understand and map to their own concepts of the objects in a digital repo.

Lobster-high-five

Rosie

[Don Richards Jr]

As we inch closer to any major changes like a migration, buy-in becomes extremely difficult (people furiously resist and fear change). As an admin preparing for this change, it becomes unnecessarily difficult to obtain buy-in when questions like these are framed as a show-stopper. As this stage of development follows a rapid iterative development model the cosmetic and user experience needs should probably not be framed in this manner. Again, all of the points brought up are extremely valuable and needs to be addressed. None of which would keep a developer (familiar with the system) from being able to preserve and display assets appropriately. Islandora 7 has had years of development and discussions to identify the UX problems and iron them out. Islandora 8 will be no exception. Thanks again Rosie for bring these points up and I'm sure the development of the next few weeks will improve the stack in ways that reflect the discussions in this feed. 

[R Le Faive]

Not a show-stopper!  Don't think I phrased it as such.

But it's not purely cosmetic, either. 

Currently, the definition of an islandora object is: "a node of an Islandora Content Type. And an Islandora Content Type is any content type configured to do Islandora things. And the Islandora things are all optional, though you probably want to push to Fedora, which requires specific fields to be present. Also, "having media" and "being members of" are things that islandora nodes might do, but we've set it up so that any node can too." 

There's been an implicit assumption that "regular drupal nodes" are not "islandora nodes" but by that definition it's impossible to draw a line. 

We're going to want to treat Islandora stuff and non-Islandora stuff differently. At some point someone, dev or no, will have to be able to make a binary distinction, whatever the criteria. Without a distinction, we're just talking about nodes, and we can't build an interface or a back-end that makes sense to someone who wants to "use islandora" as both a CMS (non-islandora) and a repo (islandora). 

So yes, there is a way to make an islandora object and have it do all the things you expect it to do. If you're a dev. But there are also a thousand ways to screw up making an islandora object, both as an admin and as someone entering content. Mismatched Islandora Type and Media Type? Wrong tags? Member_of doesn't allow the right content type? Using the interface to make an islandora object correctly feels like Catherine Zeta-Jones dodging lasers, blindfolded, in Entrapment. You have to memorize an incredibly complex web of gotcha's, there's no way to see whether you're doing the right thing, and there's no feedback if you do it wrong. Devs, you're going to get frustrated at walking people through it. Users, you're going to get frustrated because the devs can see laser beams that you can't. 

To work this metaphor into the ground, ideally the path to creating an islandora object would be a well-lit, accessible hallway. You upload your file and what metadata you have. But to build a hallway like that someone needs to configure file requirements and metadata profiles and all the things that we want to remain configurable. If it's a maze-until-configured, we should at least make the lasers visible and give better feedback. 

It seems to me that without a definition, we can't provide guidance, and without guidance, we're putting our users at an unnecessary disadvantage, and it doesn't have to be so hard. 

The amount of features that have been ported to 8 is phenomenal. And so far, we've been able to avoid making structural constraints around Islandora. But I am trying to convince the community that this is the time to decide: Is there a distinction? Is it something an individual site configures, or is there a core property that makes an object islandora? If there is a core property, what is it? And if there is a binary distinction, how can we use it to make a coherent yet configurable system within the Drupal framework? I would argue that question isn't one of UI sugar, but touches the core of what it means to be an Islandora system. 

[Danny Lamb]

Rosie,

We attempted to address a simplified ingest before release.  Here's the issue we had going for it: https://github.com/Islandora-CLAW/CLAW/issues/919  Unfortunately, the week before release a lot of stuff got merged in, some of which conflicted with this.  So we reverted the simplified ingest form.  It got auto-closed by Github when we merged the original PR, but I've re-opened the issue.  It's still something that everyone wants, just was an unfortunate casualty of keeping things lean and working for the release :(

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/970388a8-3295-4df1-a25f-7547ef56d82d%40googlegroups.com.

[Alexander O'Neill]

On Aug 28, 2019, at 1:16 PM, Nia Kathoni <nika...@gmail.com> wrote:

Good read indeed. One thing I could suggest if not too late in the process it would have been good to build inslandora objects as drupal custom content entities instead of node (https://www.drupal.org/docs/8/api/entity-api/introduction-to-entity-api-in-drupal-8). 

Nia

As an addition to this I think it would have been / would be good to not use Drupal’s ‘Media’ entity type for Fedora binary objects as it steps on their normal use and seems to cause confusion in naming.

 - alexander

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/1b3ca0b0-07d5-4b99-8ab8-1dbd272e6b7d%40googlegroups.com.