August 1, 2018

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

Time: 1:00pm Eastern Daylight Time US (UTC-4)
Zoom link: https://zoom.us/j/203396828
IRC:
- Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #islandora on irc.freenode.net

https://github.com/Islandora-CLAW/CLAW/issues/887
If you request JSONLD from Drupal, all the URLs are suffixed with the request parameter
Hopefully get some more voices and opinions
A simpler URL might be best
Current workaround for lack of content negotiation is in the REST API
You cannot currently query Drupal for what MIME types it will accept
There is a work around using another REST query

How can we better handle the tags
We should spilt them into multiple vocabs and fields
e.g. Access Control field with admin permissions
What a node represents (media type) and how it's used should be spilt out (i.e. content model)
It's just a proposal, would like to get it out of the way before demoing it to more people
Also, how we handle terms in RDF is related to this
We will probably want to:

If external URL is available, we probably want to use that (write it out)
Content model type, and media usage type, imply "typeiness"; do we want to stick with user-defined predicate?

The types related more to the object, but sometimes the object is the metadata (?)
Don't bother apply these things as RDF types
Access control is basic functionality that we should provide, at least an example

We don't currently offer a "whole object view"; you can request the media individually and the node uses Views to show some of it
We could make a amalgamated view that shows everything, but it's hairy with views within views module
Digital Echidna has an example online
Other way (more work) is to drop some tabs and display them as blocks instead (attachments)
Could make a cleaner single display for your average user, and show the blocks for the admin users
We've structured things to align with Fedora's idiosyncrasies (i.e. the many members problem)
We get a performance boost but we lose the singular document that's the whole object
It's possible to request api-x something that would amalgamate everything
You could also index a full document using blank nodes (resource map)
Fedora doesn't have a means to search itself (it's odd)
Real way is the index everything is a triple store as a named graph, and you'd request that named graph
Fedora also doesn't have a way to list it's contents, but you can walk though it using the UI
It's been left open on purpose, needs to be refined based on user feedback
Can use SPARQL to query Fedora
We are not going to orphan objects in Fedora
It would would be good to document all the pieces that make up an "object"
Our object model as of now is us trying to replicate the 7.x model without running afoul in either Drupal 8 or Fedora 4

This is an archive. For new Tech Call notes, click here