display a dependency tree (imported ontologies)

[JJ-Author]

Detect imported ontologies (based on owl:import statements) and

• show them as dependency tree on the frontend
• map/hyperlink the dependencies dynamically based on import statement to the specific imported version (respect the owl:versionIRI or owl:versionInfo statement if specified otherwise match via archiving timestamp(s)) to version archived in archivo and also display the latest version that is archived
• show availiblity status badge for dependencies (for archived ones only for now)
• optionally aggregate some of the statistics (e.g. triple count, bytesize ...)

[GOVINDFROMINDIA]

I have an answer to this issue:
1 Use a web framework and an OWL parser to build the backend of the application.
2 Store the parsed ontologies and dependencies in a database.
3 Use a frontend framework to build the user interface, including the dependency tree and availability status badges.
4 Use the Archivo API to dynamically map/hyperlink the dependencies to their specific imported versions and display the latest version.
5 Use a status monitoring tool to check the availability of the archived ontologies and display their status badges.
6 Optionally, use a statistics library to aggregate statistics for the imported ontologies and display them in the frontend.

Please assign me this

[JJ-Author]

hello @GOVINDFROMINDIA, sure most of the artifacts and tools needed for that are already existing in archivo. so it is more like adding and extending the calls at the exact places and extending the UI view. @yum-yab can you please guide @GOVINDFROMINDIA ?

[yum-yab]

Hi, thank you for helping, this could be a very nice addition!

So currently most of the stuff in the list is already implemented in some way, the goal should rather be gluing them together instead of reinventing the wheel:

• Uptime monitoring already happens during crawling, no need to reimplement that
  • the access to that can be handled later, this part has no high priority
• it won't be necessary to use a database, because once we actually use it it should be stored persistently and accessible in a SPARQL endpoint
  • the question is rather: HOW to serialize a dependeny tree (in RDF)?
  • once we have it as RDF it is really easy to store it in an SPARQL endpoint (we will use Databus Mods in the future for that, but one step after another :))

What are the next steps?

You already built a prototype for recursively fetching the dependencies of an ontology, which is great, but to be usable for Archivo a few more steps are necessary

• open up a github repo for the project
  • In the future it should be its own microservice rather than part of archivo (which in the future will only be a crawler+webpage, nothing more)
  • you can also create a branch of this repo, but you probably won't need much of Archivo's codebase
• You already write a script to fetch the dependeny URIs, so the next step would be mapping the results to a certain Archivo version
  • so that instead of ontology URI a URI of an archived version is given
  • would be nice to check the time of submission so that the latest version of the imported ontology at that point in time is used (if not overwritten by owl:versionIRI)
  • maybe in the future there will be a service to check if ontology is already part of archivo, but for a first rough implementation it will suffice to use that function to generate group + artifact and check if https://databus.dbpedia.org/{group}/{artifact}/ exists (simple head request or SPARQL or whatever)
  • you can also use the Archivo API, so simply calling curl -L -H "Accept: text/turtle" https://archivo.dbpedia.org/info\?o\=http://meta.icos-cp.eu/ontologies/cpmeta/ gives you the RDF of the Datasets (it is far to much information, for the basic you just need to check wether Archivo finds something or not)
• storing the dependency tree in an usable format
  • RDF would be nice, since we can query it directly without loading the file first
• think about a way how it should be displayed in the frontend
  • since it can be changed in any way once we have a useable datastructure, the first two steps are more important at the start
  • maybe it would also be better to introduce a single page for one version of an ontology (just an idea)

@GOVINDFROMINDIA If you want to tackle this project I'll be happy to help you, message me (write a mail or message message me on the DBpedia Slack) if you need help or maybe we can have a quick talk about the project :)