search

mmisw / orr-portal

ORR Frontend component
Apache License 2.0
8 stars 5 forks source link

investigate integration of Widoco metadata with ORR #130

Closed graybeal closed 4 years ago

graybeal commented 5 years ago

Widoco (http://dgarijo.github.io/Widoco/) seems to be a very nice documentation tool for ontologies, and their recommendations (http://dgarijo.github.io/Widoco/doc/bestPractices/index-en.html) seem to be nice too (though MOD attribute list is more comprehensive: http://www.lirmm.fr/~jonquet/publications/documents/Article_MTSR-2017_MOD1.2.pdf).

The goal is to evaluate the adoption of Widoco as an ORR-supported documentation tool, that could present to end users additional views documenting their ontologies. I do not have any idea whether this is even realistic (as Widoco seems to be a standalone tool) but I wanted to capture the possibility.

This would require adopting a compatible metadata standard for use within the ontology documentation as well, I expect.

carueda commented 5 years ago

@graybeal, @lewismc Just marked this as 'good first issue' especially given its "evaluation" nature. Please chime in if you have any reactions to this. Thx!

lewismc commented 5 years ago

WIDOCO itself is pretty cool however there are two things wrong here IMHO

graybeal commented 5 years ago

what happens if the new comer doesn't even really know what an ontology is? Say they just want to develop and improve the portal?

As with all newcomers (and existing developers), their work is evaluated as they present it. Even without any knowledge of ontologies, I could make a reasoned pass at how to include or reference an external system like WIDOCO, demonstrate it in a branch on my own machine (caveats below re complex integration), and identify issues and benefits that I see. Then the people evaluating whether to incorporate my work could comment and determine whether it is heading in an acceptable direction, or what would need to change.

WIDOCO is a standalone application... meaning that currently we need to download and install it, currently this makes it unusable in COR.

I don't know how to interpret this. It is usable by COR if the developer downloads and installs it on the COR machine—or on another machine—from which COR could run the CLI, yes? Or does it require operation from a UI? (Sorry, if I had more time I'd go look this up, I'm being bad.) I know Carlos doesn't like having more software running on the COR machine, and if we agree that makes sense, WIDOCO may be a non-starter—or maybe could be run as a separate hosted system. Somewhere.

We 'could' however work with the WIDOCO team to have the artifacts published to Maven Central.

What is the advantage of having it in Maven Central, as opposed to GitHub? (I'm assuming you mean code artifacts, not the actual WIDOCO outputs.)

Please chime in if you have any reactions to this.

I think there is likely to be a significant integration challenge, in that a lot of different artifacts get produced and then must be accessed/displayed from COR. However, if the first task is framed as performing the analysis—testing the system and evaluating how it could be integrated with COR, and writing up how hard that would be—then it is a low-risk thing for someone to do.

But there are significant other tasks that I think would be needed. In particular, the COR metadata needs to be aligned with this, and (IMHO) with the MOD metadata recommendations (I think that's in another task?). And that strongly suggests that we should communicate with the WIDOCO team to see if they are willing to get aligned with MOD recommendations.

carueda commented 5 years ago

Agree pretty much with John, especially re the evaluation nature of this entry as I already mentioned.

(oh, just a precision: it should be just OK to have "more software running on the COR machine" as long as it has the relevant compute/space/admin resources.)

kunakl07 commented 5 years ago

@lewismc Sir, I would like to work on this issue

lewismc commented 5 years ago

@kunakl07 OK, so have you built ORR yet using the Docker deployment?

If so then I advise you to start looking at editing the portal code to implement some features. The issue is pretty well described above. Do you need more guidance/ If so please explain what it is that you need guidance on. Thanks

lewismc commented 5 years ago

Hi @graybeal I had previously not built Widoco or used it... I just did both and would like to start working on this issue but there are a few things we need to iron out. Rather than going through what each one of them is, I am instead going to propose what I think we should do.

Current Resource Page Layout Very simply put, a resource metadata window is positioned above a tabular data window which offers various ways for interacting with the data. imageedit_2_6273091994

Proposed Resource Page Layout All of the following metadata should be captured in the Widoco representation

Screen Shot 2019-09-24 at 5 36 02 PM

Embedding Widoco in this page would also remove the bottom data panel as well by providing all necessary information and vizualization. The following shows embedded WebVOWL as well

Screen Shot 2019-09-24 at 5 42 01 PM

What do you think about the proposal above?

In summary here are some of the selling points

lewismc commented 5 years ago

I traced the code which pulls in appConfig.externalTools.ontViewers to ont-data.js which is then rendered in the ont-data.html template.

I don't think it would be much work to simplify the deployment but I am not very familiar with Angularjs so would need to step through this with @carueda

The primary question I have right now is whether we would want to run Widoco ad-hoc e.g. whenever a page is rendered... or else pre-generate all of the outputs. Based on peformance concerns I had using Widoco locally I would prefer we pre-generate everything but this introduces some new questions

The above questions become non-trivial and would take quite a bit of additional work. Can you guys think of anything else?

lewismc commented 4 years ago

I propose to close this issue off and work together on implementing the plugin for pyLODE https://github.com/RDFLib/pyLODE If there are objections @graybeal then please re-open.

carueda commented 4 years ago

@lewismc Sorry, I realized I lost track of this one and missed to note your good points. But I would agree we could revisit them in the context of enabling pyLODE. (In any case, the Widoco system seems very appealing as well, so we should keep it in mind anyway, I think.)