IIIF Annotation Demo for Vatican

[edsilv]

@aeschylus and I are scheduled to do a demonstration of image annotation using IPFS at the upcoming IIIF conference in June: http://iiif.io/event/2017/vatican/ This will entail Drew adding annotations in Mirador, and them appearing in the Universal Viewer in real time.

We were wondering if it would be possible to have a chat with @dignifiedquire and @haadcode to discuss setting up a minimal example of this using Orbitdb. Perhaps a simple text field whose contents update on a localhost server for both of us as we edit? We can then build out the rest on top of that.

cc @flyingzumwalt

[dignifiedquire]

Hey @edsilv @aeschylus lets make this happen! What's you current availability look like?

[edsilv]

I'm available all day Friday and all weekend. I'm staying at Stanford right now, so have the opportunity to work closely with Drew on this. Perhaps if you guys were free Friday around 6pm European time for an hour or two that could work?

[haadcode]

Sound like a great demo!

Unfortunately, I'm afk for couple of weeks and won't be able to work on this fully until end of April. I can, however, participate in GH to the discussion, and perhaps do a bit of code (but can't promise).

It'd be great to understand the end goal a little better. Are you thinking to expand on the previous Anno demo you did some months ago or building something from scratch? I remember the previous demo being really cool and adding the annotations with orbit-db worked nicely except the connection/connectivity problems. We've since made huge progress both in js-ipfs and orbit-db and I believe what we have today will do all of that with ease. Iirc, the main problem in the previous demo was that they weren't able to sync in real-time and you had to restart the app to see the added annotations? If so, this should be fixed and I believe upgrading the previous demo to use latest orbit-db would give us this out of the box. Adding a text field (or any other replicated data/object) should be fairly simple, too.

Is there anything complex to the programs/apps you plan to use to demo or are they both browser apps? Is there a need to run something in the background or on a server?

@edsilv in terms of code, do you feel like you can get started based on the documentation and examples there are for orbit-db or is there something you're unsure what/how to do? If there's something you're missing, let us know and we can come up with examples on how to do a specific things or provide better documentation. If you're wondering how to model the data in the demo and how to use orbit-db to do that, let us know and we can provide suggestions how to use the different database types efficiently.

Looking forward to see this happen! :)

[edsilv]

It should all be browser based I think. Are you thinking that we can use js-ipfs on both apps without a go-ipfs daemon running? This is basically witchcraft to me right now :-) But if there's an example of this that would allow us to keep track of a "head" with changing data behind it that should be enough. We're basically just going to be generating an annotation list like this from mirador:

http://wellcomelibrary.org/annoservices/search/b18035723?q=gene

and subscribing to it in the UV and displaying as "search results".

Any pointers you can offer are greatly appreciated :-)

[aeschylus]

@haadcode cc:@flyingzumwalt, @dignifiedquire

Hi all, @edsilv and I have finished a basic textarea example using the browser example code. You can see this branch on our fork. It's an initial hacking of the example, so we just removed the log and count from index.js and changed the rendering around a bit.

One difficulty we had was working with the "application level" code separately from orbit. For example, it would be preferable to be able to get this example working with some code that sits outside of the build system. This seems to be how browser.html is set up, but browser.html didn't work. This wouldn't be as much of a difficulty but for the fact that @edsilv had (is having) some problems getting the build to complete on Windows (including the Linux subsystem in Windows). Once we had two macs going, we were able to rebuild the bundle.js on both machines and get one textarea updating the other and vice versa.

This should be enough for the Rome demo, but it's very naive. We used the db/"key-value" object instead of a log or feed or document. Is this right? We thought a feed would be more appropriate, but couldn't find an example for them, and this was a first hack. Eventually the idea is to share a single medium-length JSON file. Would a document be a better construct for this, or will the key-value approach work just as well?

[haadcode]

I believe this happened. Closing as obsolete.