Allow users to upload updated rdf mappings

[dannylamb]

A fully formed UI for editing metadata mappings is still pretty far out. To bridge the gap until that work is completed, it would be nice if users could upload an updated yml file through the UI instead of having to FTP or scp the file over. I'm thinking a drop-down to let the user select which mapping to replace and an upload widget would do the trick. This could live in its own form or even possibly the main islandora config form.

Uploading new mappings can be done with Drupal's existing config sync tools, so the scope of this is just updating existing mappings.

[ajs6f]

As a CLAW neophyte, can I ask you to give a quick iteration of where this kind of mapping is used? My understanding is that the RDF representation of a Drupal resource (such as gets into the backend) is whatever a client would get from the Drupal resource in JSON-LD, when requesting with Drupal's weird version of conneg. Does this YAML control that JSON-LD representation?

[whikloj]

@ajs6f yes exactly, so something like this makes the output of the jsonld for the field_member_of outputs as pcdm:memberOf where pcdm: is defined by this hook

[ajs6f]

Thanks, @whikloj! So this is a combination of YAML for the mapping with code for prefixes (!). This ticket then, isn't really specific to CLAW, right? It's something other Drupal sites might very well want as well?

[whikloj]

Totally, there is the RDFUI project, which seems like a good place to start and I have started a module to tie on to that one and allow people to register namespaces and prefixes.

This work would allow people to access their current rdf mapping config and update it. Though I think this is accessible through the Configuration Synchronization section of Drupal is it not @dannylamb?

[dannylamb]

@whikloj Accessible in the sense you can scrape it out of a web page, edit it, ssh into your server and use drush to delete the old version, and then re-upload it.

What I'm looking to do is allow you to re-upload and it will overwrite instead of blowing up and saying the config already exists. Really just trying to avoid the user from having to ssh into the server and execute drush. It's a band-aid until we can get a fully fledged UI.

[dannylamb]

Which is totally applicable to Drupal in general and not RDF or RDF mappings... but I dunno how big of a Sarlacc pit it would be for any/all Drupal config.

[mjordan]

@dannylamb anything we can do to provide as CLI-free a UX as possible for general repo admins, or anyone just testing out CLAW, would be a big win.

[DiegoPino]

I have tested the config sync for RDF mappings via Drupal's provided UI and that works (nothing classy there but it does its job), but issue is that once you update your mappings you will end with a kinda larger (sarlac type) issue: What is already in Fedora won't match what you are generating from Drupal's side.... Drupal maps are just a realtime operation, so whatever, you can change RDF mapping as many times you want (except for a safe/exception list we should have around for avoiding needed-functional predicates to be touched) but once that is done Fedora will have totally different information and so your triple store. Any ideas on how to manage that? Is the dream of back sync still alive?

[whikloj]

If RDF mappings are tied to a content type, then (correct me if I'm wrong) we should be able to view the Content page, restrict to the content type with the altered RDF mapping and push the Index to Fedora action on all those objects again. This could/would be a problem once you get a large factor of resources, but hopefully you are not changing your RDF mapping on a daily basis.

[DiegoPino]

@whikloj ok, that sounds pretty much as a full reindexing as on 7.x, like when you do Gsearch to Solr plus Triple store but in this case you also add Fedora, it is expensive but can be done. So all this would happen async of course and as a new fedora versioned resource or overwriting existing resource? Since the Node itself would be really the same, maybe not a new version right? But since also nothing writes back from fedora to islandora, then maybe yes, a version. Namespaces on the fcrepo side could be an issue DUNO, but maybe not? Feels like Fedora is just in a corner here but if the need exists, then yes, it is totally feasible. Why is the current sync UI not good enough for this?

[whikloj]

It would be a large action, depending on how many objects you have.

As for versions, that is not defined yet (ie. do we create versions for each interaction or not) but will probably be a user choice.

We don't define prefixes to the Fedora side and I'd prefer not to rely on them there. Better to use full URIs.

Not sure what you mean by "Why is the current sync UI...."? This ticket is about a UI to alter the RDF mapping, there is no UI to do that.

[DiegoPino]

I expressed myself wrongly, not saying this ticket is not valid, actually this ticket has been valid since the start and this is really needed and i could not be more grateful that is exist.

But, maybe i got it wrong: What i'm saying is that $mapping = RdfMapping::load($entity_type . '.' . $bundle); which means the mapping is in the entity/bundle configuration YAML, So the very basic UI (sync config) that Drupal provides is there for those operations.

You export for a node.something bundle, you edit and you upload back, all via a Form.

But i'm not saying that is all or that we don't need better ways of doing this. Only saying that you already can change RDF mapping in Drupal via a configuration sync using UI.

[whikloj]

@DiegoPino okay yes we are now on the same page and that is the same question I was asking @dannylamb. I was also under the impression that we could use that UI to update the RDF mapping, but maybe we can't?

[dannylamb]

Not if it already exists. Although maybe that's been fixed recently? Every time I've ever pulled something out and then sync'd it back I've gotten a big red X if it already exists. I've always had to drop into the CLI to delete the active config first before re-uploading.

[dannylamb]

Whelp... you guys are right. It will accept the upload now.

Now i'm left wondering if it was an issue that Drupal fixed or if it's never been a problem and I've just been inconveniencing myself the entire time...

[mjordan]

@dannylamb think of it as a "documentation opportunity" :smile:

[dannylamb]

Yep... totally works. I'll close this, but https://github.com/Islandora-CLAW/CLAW/issues/647 is still floating around for us to do this with a form instead of yml.