RDF UI: Ability to load different ontologies

[kimpham54]

Title (Goal)	RDF UI: Ability to load different ontologies
Primary Actor	Repository admin
Scope	access
Level	High for extending RDF UI
Story	As a repository admin, I would like to add RDF-based ontologies (including custom/local ones) to use through the RDF UI to map to the fields of Islandora bundles/entity types. Ideally, there would be an option to load ontologies by a public URL. These ontologies would be populated in RDF UI which will allow me to lookup and select the appropriate class/predicate to map the fields to.

Remarks:

• Have PCDM, DCTERMS as default ontologies already loaded and ready to use
• Possibly have BIBFRAME as a default ontology already loaded and ready to use

[uconnjeustis]

I like the idea of BIBFRAME. As the library world will move to BIBFRAME, I can see several institutions who might want this option in the future.

@mrmiguez also added these ontologies for consideration:
Europeana Data Model: http://pro.europeana.eu/page/edm-documentation
DPLA MAPv4: https://dp.la/info/developers/map/
CIDOC-CRM: http://www.cidoc-crm.org/

[ajs6f]

CIDOC-CRM in particular raises the question of managing internationalized vocabulary in a UI. Maybe best broken off as a separate ticket.

[DiegoPino]

bibframe++, I guess we are thinking about version 2 right?https://www.loc.gov/bibframe/docs/bibframe2-model.html
I always loved the idea of the simplicity that classes that represent real human creative dimensions provide or how we, in fact, describe and see our past (agents, events, places, etc)

@ajs6f true about CIDOC-CRM

I see two different things here (and a third which is a mix of both): A) Ontologies with their classes and properties, which can be incorporated as defaults in an eventual uptake of RDF UI by us, and B) Data models, with their mappings and "how to use" web pages, being the latter probably out of scope of the RDF UI itself (in terms of the functionality it provides as Drupal module), more into the way we right now link bundles and manage these hierarchies, and also, as always, very complicated to implement since they require, most of the time, a human involved data structure (relational DB way thinking) to be implement and all kind of exceptions in code to be implemented.

Side note (skip if you have more important stuff to do) ->In specific, about the CIDOC-CRM, I wonder how stable that one is, and how much extra benefit it adds versus complicating things: Like its "the graphical representation" http://cidoc-crm.org/cidoc_graphical_representation_v_5_1/graphical_representation_5_0_1.html, looks overwhelming and the printer friendly version is a powerpoint! and entities linked to non-existing pages(maybe I don't get the meaning of a 404 😸 ). As always, this raises the question of how many ontologies are born every day, versus how many survive the harsh winter, the lack of resources and human contributed time to maintain them.

[ajs6f]

OMG PLEASE LET IT BE Bibframe 2. I just assumed that it was. The first attempt was a wide-awake nightmare and should be banished from all sane minds forever.

[ajs6f]

@DiegoPino CIDOC-CRM is very definitely successful. I'm not saying that it is well-documented, just that it is in wide use globally. It has much more uptake than Bibframe and that's not going to change-- Bibframe is of interest to a tiny community of bibliocentric cataloging librarians who are now manacled to MARC, CIDOC-CRM is of interest to a much larger community of communities (e.g. archivists, curators, archaeologists and anthropologists, art historians, etc.)

Incidentally, last I checked, DPLA's model is based on CIDOC-CRM.

[DiegoPino]

@ajs6f cool, wow about CIDOC-CRM, the docs are a living nightmare! I'm learning, slow and steady, thanks for the clarification, I do agree(well, i agree on everything) on bibframe2 being more "here" centric, as is MODS also. I thought DPLA stuff was more derived from Europeana one, being that more derived from ORE, etc. I learn so much from you! 👍

[ajs6f]

No, no, I think you are right @DiegoPino -- it was EDM, directly. I spaced out on that. But notice that EDM itself imports the CIDOC-CRM namespace. So it's not a big difference either way.

[dannylamb]

Transferring to Islandora-Labs/rdfux#5