Generating documentation of non-derreferenceable imports is problematic

[dgarijo]

Maybe WIDOCO could ask the user to resolve the dependencies manually if an error is detected when loading.

[rjyounes]

How about allowing adding a mapping to the config file, mapping ontology IRIs to files on the file system?

[dgarijo]

At the moment I read the ontology with the OWL API and fail silently if there are any errors. Instead of failing silently I could then ping the user to solve the issues or resort to something in the configuration. Thanks for the idea!

[ghost]

That would be very useful. I have multiple ontologies that depend on each other and are developed together. Generating the documentation is difficult, because I would have to publish some of them first.

[Michiel-s]

Hi @dgarijo.

First of all, thanks for your great repo.

Do you have any update on this issue?

I use the CLI in my Dockerfile: java -jar /usr/bin/widoco.jar -ontFile ontology-index.ttl -outFolder doc -webVowl -lang en-nl

I'm working on generating documentation for a complete set of ontologies that is developed as a whole but split into several files. My project folder looks like:

|_ ontology-index.ttl
|_ catalog-v001.xml
|_ taxonomies
  |_ skos-taxonomy-1.ttl
  |_ skos-taxonomy-2.ttl
|_ core
  |_ file1.ttl
|_ ...

My ontology-index.ttl contains:

...
my-ontology:
  rdf:type owl:Ontology ;
  owl:imports
    <http://www.w3.org/2004/02/skos/core> ,
    <https://example.com/my-ontology/taxonomies/Taxonomy-1/> ,
    <https://example.com/my-ontology/taxonomies/Taxonomy-2/> ,
    <https://example.com/my-ontology/core/> ,
    ;
.
...

Obviously only the skos import works. The other imports cannot be resolved when developing locally.

Protoge (and other tools) use the XML Catalog for this. My catalog-v001.xml looks like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<catalog prefer="public" xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
    <group id="Folder Repository, directory=, recursive=true, Auto-Update=true, version=2" prefer="public" xml:base=""/>
    <!-- Taxonomies -->
    <uri name="https://example.com/my-ontology/taxonomies/Taxonomy-1/" uri="./taxonomies/skos-taxonomy-1.ttl"/>
    <uri name="https://example.com/my-ontology/taxonomies/Taxonomy-2/" uri="./taxonomies/skos-taxonomy-2.ttl"/>
    <uri name="https://example.com/my-ontology/core/" uri="./core/file-1.ttl"/>
</catalog>

As you can see, here the mapping is specified from URI to local file. When I load ontology-index.ttl into Protoge, it automatically recognizes the catalog file in the same directory and knows how to resolve the imports.

Would that be a solution to add to Widoco?

[dgarijo]

Hi @Michiel-s, thanks for giving Widoco a try! I haven't pushed this issue further (I haven't had much time for it). Since it looks like it's a feature that would be wanted by several people I will include it in the next milestone.

Your suggestion is a good idea, I can look for this file, although it won't work if you have worked outside protege. So in the end resorting to some local config to solve this issue seems like the path forward.

[Michiel-s]

That would be great. Please let me know if I can be of any help.

[JohannesLipp]

It could be an option to supply such a mapping of ontology URIs to custom (local) paths via the configuration file. We cannot do this now, but it could be a feature :)

[dgarijo]

I agree, that would be the path of least resistance (no pun intended :D). This would require:

• Have the configuration to solve these mismatches.
• When there is a mismatch, try to look for the catalog-v001.xml file to solve it first.

[GenEars]

Hello @dgarijo It looks like this issue is also true when there's some URL rewriting at remote server side : Widoco sees remote URIs as non-derreferenceable (i.e. non accessible) although a specific navigation scenario is implemented on the server side.

For example, a standard http request will send users to some html page describing the ontology, whereas using specific HTTP Accept Headers on same URL will trigger an ontology spec export as a turtle file or instances export after some SPARQL request (see Virtuoso's doc about this here).

So my point is that your import mechanism through OWL API - or whatever - could use HTTP Accept Headers for managing such false non-derreferenceable situation.

Maybe that's too far from your import policy, anyway I hope it helps.

[dgarijo]

Hello, I wrote the content negotiation from scratch on Widoco because owl API did not work in some cases. The negotiation follows 303, 302 and 301 redirections to remote servers. An example are ontologies with w3id, which are negotiated in the w3id server and then served in many cases as GitHub pages. Accept headers are used to try and retrieve different serializations. Do you have an example to have a look at?

If this is not covered by the solution discussed in this issue, please open a new one. I would like to spend some time making sure this works fine.

El jue., 23 dic. 2021 11:34 a. m., GenEars @.***> escribió:

Hello @dgarijo https://github.com/dgarijo It looks like this issue is also true when there's some URL rewriting at remote server side : Widoco sees remote URIs as non-derreferenceable (i.e. non accessible) although a specific navigation scenario is implemented on the server side.

For example, a standard http request will send users to some html page describing the ontology, whereas using specific HTTP Accept Headers on same URL will trigger an ontology spec export as a turtle file or instances export after some SPARQL request (see Virtuoso's doc about this here http://docs.openlinksw.com/virtuoso/urlrewriting/).

So my point is that your import mechanism through OWL API - or whatever - could use HTTP Accept Headers for managing such false non-derreferenceable situation.

Maybe that's too far from your import policy, anyway I hope it helps.

— Reply to this email directly, view it on GitHub https://github.com/dgarijo/Widoco/issues/306#issuecomment-1000204035, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALTIGWUACX5FCTCFBKRF6LUSL3MBANCNFSM4FVYJORQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>