Create IIIF/SC Ontology

[azaroth42]

Make a real ontology doc for Shared Canvas

[ndushay]

@azaroth42 yes please. If you do it, I can do the pull request for rdf-vocab gem.

[ndushay]

blocks sul-dlss-deprecated/rdf-iiif#1, which blocks sul-dlss-deprecated/triannon#164

[azaroth42]

Done. Waiting for it to be merged to master to deploy to live site, but it's also at
http://prezi_ontology.iiif.io/api/presentation/2/ontology.xml in the mean time

[azaroth42]

http://iiif.io/api/presentation/2/ontology.xml I can try to make the namespace redirect to this doc when I'm on campus.

[dazza-codes]

WRT #3, when this ontology becomes part of RDF::Vocab, create a new issue to use that code instead of lib/rdf/vocab/sc.rb and assign it to me.

[ndushay]

I submitted ruby-rdf/rdf-vocab#14 for IIIF vocab, and also requested new rdf-vocab gem release after it is merged.

@azaroth42 - not sure if @darrenleeweber also needs ontology for http://www.shared-canvas.org/ns/ I will leave it up to you two to deal with that -- creating shared canvas vocab from ontology and doing PR to rdf-vocab if nec, etc.

[azaroth42]

The two are the same, just with a different namespace. We moved it to iiif so that we could provide better support (which clearly we have failed to do until now!)

[dazza-codes]

I think the short-answer is 'yes', we also need an ontology with class URIs that match the SC namespace. The related code in sul-dlss/annotations2triannon is in
https://github.com/sul-dlss/annotations2triannon/blob/master/lib/rdf/vocab/sc.rb
which is used in various places like
https://github.com/sul-dlss/annotations2triannon/blob/master/lib/annotations2triannon/manifest.rb#L19-L21

[ndushay]

Could you do a redirect from RDF::SC to RDF::IIIF using that const_missing approach I'm using for rdf-ldp gem class level deprecation? Or some similar footwork to convert namespaces on the fly?

[dazza-codes]

I think this is a backward compatibility issue with regard to the use of the SC vocab in any data sources. The a2t gem should support any SC vocabs. If there is a 'magic' way of creating an RDF.rb graph with a lot of owl:sameAs relations between SC and IIIF2, that might achieve the same result, but I think that's a lot more tricky than simply creating the ontology (esp. since I have already done a lot of the work in the sc.rb file and it can be easily translated into ttl and then possibly loaded into Protege as an RDF source, from which it might output an OWL file?).

[azaroth42]

Would it help if I made those owl:sameAs relationships in the iiif ontology doc? I can trivially automate that.

[ndushay]

Maybe I'm being thick here, but why is it useful to preserve the old outdated namespace for those annos? Is that namespace information important? If we have a fairly painless upgrade path for those annos, aren't we reducing future headaches by upgrading the annos to the iiif namespace? Note: I'm not saying in general namespaces can be substituted. But in the case of this spec, which is very recent, and this data, which is also recent and fairly well understood -- what is the risk?

• a2t code should accept annos in either namespace
• a2t code can convert sc namespace annos into iiif namespace
• a2t should write iiif version of anno, without additional noise from "sameAs" triples, to triannon.

[dazza-codes]

Ah, yea, maybe, but all that entails work and I just think it's easier to create the SC ontology.

[azaroth42]

In terms of making our lives easier down the line, it seems valuable to rewrite the older namespace to the new one. We don't want to have to write queries against both when the data ends up in a triplestore. It seems like it's just a case of a string search/replace for the old namespace to the new, before parsing the data? Or is it more complex than that?

[dazza-codes]

Related issue now closed (won't fix), so noting it here for reference

• Seeking help with a shared canvas vocabulary ruby-rdf/rdf#171

[dazza-codes]

The points about the SC namespace imply that it is or should be deprecated, which could have implications for code in this project, i.e.

• https://github.com/sul-dlss/annotations2triannon/blob/master/lib/annotations2triannon/shared_canvas_annotation_list.rb should be deprecated?
• https://github.com/sul-dlss/annotations2triannon/blob/master/lib/annotations2triannon/shared_canvas_manifest.rb should be deprecated?
• all the SC methods in https://github.com/sul-dlss/annotations2triannon/blob/master/lib/annotations2triannon/manifest.rb should be deprecated?

If so, as a matter of process, the SC namespace should have been deprecated prior to work on this project. If the SC namespace should be deprecated, the implication is also that all the DMS annotation data should not and will not contain any SC entities (the first motivation for working with SC arose from parsing the DMS annotations).

If the assumption of SC deprecation is wrong, then we need a solution for supporting it. The current solution works, but I have no idea whether it is an entirely correct solution, i.e. see

https://github.com/sul-dlss/annotations2triannon/blob/master/lib/rdf/vocab/sc.rb

This vocabulary may or may not be correct or consistent with the spec that is (or was) SC.