better display of regular ontology

[carueda]

Currently, ontologies not built with the ORR tools are dispatched in a rather simple way: in a 3-column table corresponding to the triples in the ontology.

So, this is about exploring and incorporating a better display mechanism, ideally with a tool that can be easily embedded. (Note, this task is not about editing as this is out of the scope of the ORR.)

• Possible options (not necessarily mutually exclusive):
• Our own orrv prototype, which with the MMI Device Ontology looks like shown in this link: http://mmisw.org/experimental/orrv/#/uri/http://mmisw.org/ont/mmi/device
• http://vowl.visualdataweb.org/webvowl is a very interesting graphical tool. With the MMI Device Ontology: http://vowl.visualdataweb.org/webvowl/index.html#iri=http://mmisw.org/ont/mmi/device looks like this:

[carueda]

Added configuration entry to indicate external ontology viewers than can be dispatched with the ontology URI in a parameter. At the moment with the VOWL tool in the master configuration. This can be disabled/extended/overwritten in the local.config.js file as needed.

  externalTools: {
    // ontViewers: List of external ontology browsers/visualizers.
    // These will be shown as options to display ontologies not created by the ORR.
    // They are are dispatched in an iframe.
    // Use `$uri` to refer to the ontology URI in srcUrlTemplate.
    ontViewers: [
      {
        name: 'WebVOWL',
        title: 'Web-based Visualization of Ontologies',
        srcUrlTemplate: 'http://vowl.visualdataweb.org/webvowl/index.html#iri=$uri',
        moreInfoUrl: 'http://vowl.visualdataweb.org/webvowl.html'
      }
    ]
  },

The default display is with the built-in "triple table" as before. With the VOWL option looks like this:

It would be better to have a local deployment of the VOWL tool (including the required conversion tool OWL2VOWL) so as not to depend on the availability of the external service. But this would require some work. Let's see how it goes like this for the time being.

[carueda]

With the addition of LODE (#83) I'm closing this one.

I'm not saying that this is a perfect solution, but seems like at least acceptable for the time being.

Let's just open other entries in case of more specific issues/needs.

[carueda]

I'm reopening this entry with the idea of actually having local installations of (at least, initially) the LODE and VOWL tools. The already existing mechanism to enable such tools won't need to be changed. We could first tests things on any of our "controlled" ORR instances (COR, in particular), and then perhaps create and use docker images for such tools to facilitate their deployment for other instances.

@lewismc FYI

[lewismc]

ack @carueda this would provide better functionality for COR users for sure.

[lewismc]

@carueda I'm not sure if this issue should be kept open any more. Although it takes a while, LODE does work. Unless we run an instance of LODE as a docker container alongside the existing deployment then we simply need to accept external dependency on LODE (or whatever else someone wishes to configure in the future).

[carueda]

@lewismc Thanks, yes it makes sense to close this one.

Well, mainly because:

• there's configurability in the ORR to point to external services
• so, each concrete ORR instance (like COR) can decide which external tools to "integrate"

Now, re specific tools, it would be convenient to have local installations of them to avoid relying on the external service, which could probably be over-loaded if exercised from many places, etc.

Besides LODE, it would be good to revisit VOWL.