[BUG]Broken imports

[marwa811]

Hello All, Thanks for your efforts in developing the SWEET ontology. I am using it with other bioportal ontologies but I am stuck on unworking imports in SWEET owl file.. Actually, there are a large number of those unworking imports (not only one or two).. Could you tell me if you are modifying them soon?? or is there a solution to get the correct imports?

Regards, Marwa

[graybeal]

Can you clarify in which of the SWEET distributions you are seeing the unworking imports, and provide examples of what's not working? I looked in the BioPortal log and am not seeing any issues.

Most people who want to work with all of SWEET are encouraged to use https://sweetontology.net/sweetAll, which should incorporate all the ontologies without the need to resolve all the imports. But it will be good to hear where you think the imports are not working.

@lewismc @brandonnodnarb At the moment it looks like PyLode is not displaying classes etc. correctly at that IRI, and the Raw view ends up reverting back to the PyLode, not providing a raw TTL file.

[brandonnodnarb]

@marwa811 +1 to clarifying which error(s) are you receiving.

Is it a 403 error? If so, there has been a long standing issue with CloudFlare, see issue #150. So, for me, loading an ontology from URI in Protege using https://sweetontology.net/sweetAll throws a 403 error. This is also the case if I try to load any SWEET ttl file from URI.

As such, when using Protege I load everything from local by using the replacement catalog-v001.xml which redirects all import statements to my local copy.

@graybeal, I'm not sure what is meant here:

Most people who want to work with all of SWEET are encouraged to use https://sweetontology.net/sweetAll, which should incorporate all the ontologies without the need to resolve all the imports.

sweetAll has no classes or properties, it is only a set of import statements to load all ttl ontology files [1].

As for the PyLode issue, is this because there are no classes in sweetAll? Other ttl files seem to be working as expected, for example hitting https://sweetontology.net/matrElement resolves to the PyLode page with classes, instances, etc. displayed.

[1] Please note: to load all ttl files you need to load sweetAll_includeV23Comments.ttl which, in addition to loading all ttl ontology files, loads the rdfs:comments from previous version --- which are meant to be temporary while the comments/definitions issues are being sorted.

[marwa811]

Thank you for your response, for the version I downloaded the OWL file from bioportal latest version (3.5). I am using OWL API to parse ontologies but for loading SWEET I got "org.semanticweb.owlapi.model.UnloadableImportException: Could not load imported ontology: http://sweetontology.net/human Cause: Server returned HTTP response code: 403 for URL: http://sweetontology.net/human". Although this import is working now but still have the same exception each time I try to load SWEET. Also I have another question, why I found that SWEET.owl do not have classes or properties only imports to other ontologies? does this means that SWEET consists of all of those ontologies all together?

Regards, Marwa

On Mon, Jul 19, 2021 at 1:21 AM brandonw @.***> wrote:

@marwa811 https://github.com/marwa811 +1 to clarifying which error(s) are you receiving.

Is it a 403 error? If so, there has been a long standing issue with CloudFlare, see issue #150 https://github.com/ESIPFed/sweet/issues/150. So, for me, loading an ontology from URI in Protege using https://sweetontology.net/sweetAll throws a 403 error. This is also the case if I try to load any SWEET ttl file from URI.

As such, when using Protege I load everything from local by using the replacement catalog-v001.xml https://github.com/ESIPFed/sweet/blob/master/catalog-v001.xml which redirects all import statements to my local copy.

@graybeal https://github.com/graybeal, I'm not sure what is meant here:

Most people who want to work with all of SWEET are encouraged to use https://sweetontology.net/sweetAll, which should incorporate all the ontologies without the need to resolve all the imports.

sweetAll https://sweetontology.net/sweetAll has no classes or properties, it is only a set of import statements to load all ttl ontology files [1].

As for the PyLode issue, is this because there are no classes in sweetAll https://sweetontology.net/sweetAll? Other ttl files seem to be working as expected, for example hitting https://sweetontology.net/matrElement resolves to the PyLode page with classes, instances, etc. displayed.

[1] Please note: to load all ttl files you need to load sweetAll_includeV23Comments.ttl which, in addition to loading all ttl ontology files, loads the rdfs:comments from previous version --- which are meant to be temporary while the comments/definitions issues are being sorted.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESIPFed/sweet/issues/254#issuecomment-882131075, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACLV2MXDLQG3HCVY4QIT36DTYNOZNANCNFSM5ASP2QRA .

--

Marwa Hussein M. TA @ Information Systems Department Faculty of Computers & Information Assuit University @.***>

[graybeal]

Thanks for the clarifications @brandonnodnarb , sorry for my confusion. (@marwa811 Yes, SWEET does consist of all those ontologies together, as he describes.) You may be right about PyLode not showing imported classes.

I didn't know we were still plagued by the cloudflare issues, I thought those were resolved. Should we tag an ESIP person to tag the cloudflare rep on this? It does seem like it might be the cause for @marwa811 's issues.

[brandonnodnarb]

@marwa811 thanks for the info. It looks like you are receiving the 403 http error response code which requires further investigation.

As for this:

Also I have another question, why I found that SWEET.owl do not have classes or properties only imports to other ontologies? does this means that SWEET consists of all of those ontologies all together?

Which OWL file are you referencing? SWEET was developed as interoperable modules consisting of about 225 ttl files broken up by process, domain, state, and similar. These files can be loaded all together, which is what we have been discussing, or smaller modules can be loaded individually. In either case each file will have its own classes, properties and so forth as well as importing the classes and properties required from other modules.

I hope this helps.

@graybeal --- I'm assuming this is the same as #150 based on description coupled with personal experience of not being able to load SWEET via URI in some time. I wasn't part of the previous discussion(s) but can raise the issue again.

[graybeal]

I think it may be caused by the same mechanism (i.e., something cloudflare-related) but I don't know that it's exactly the same. I'm not even sure the best way to investigate, but if you need me to check with Protege I can. In BioPortal the easiest way to check is with a new release of SWEET... I could test with our staging system to see if SWEET parsing is still working. Let me know what you want on those scores.

I see SWEET is still at 3.5.0 (since Dec 2019), is it close to getting at least a minor point release?

[marwa811]

Actually, I am not aware of "cloudflare" or the technical details of how SWEET works. What I understand from our discussion is that SWEET consists of a set of imported ontologies and now they are all working fine but when trying to load SWEET ontology using owl API I got "can't load imported ontologies" exception. I can't understand how the URIs in working fine but the OWL API code catch such exception?? And If SWEET version 3.5.0 released Dec 2019 seems to be an old one, how can I get the latest version?

[graybeal]

Yes, sorry, we're essentially doing internal troubleshooting discussions via this thread at this point, your first paragraph is basically correct.

Summarizing what's in the referenced tickets, there is internet hosting/service providing software that for some reason does not allow certain kinds of internet accesses when requested from Java 8.0 clients. So the first request works fine, but subsequent requests are made from the hosting repository running on Java 8.0 libraries, and those are rejected. It isn't 100% sure that's our problem, but it is suspicious because of previous history.

Unfortunately it is hard to get attention on this re-occurrence of this problem at the moment, because everyone is attending and providing presentations at the ESIP workshop this week. But if you can work with the SWEET content on your local system, here is how you can get it. Visit https://bioportal.bioontology.org/ontologies/SWEET, and look for the Submissions section in the lower left (seen in the image below). If you click on the OWL link in the most recent submission, you will see the original ontology, that includes all the #import statements. If you click on the RDF/XML link in the same line, you will get an RDF file that reflects all the imported ontologies. (This is the ontology as processed by BioPortal.)

The problem itself may take some time to sort out anyway, because (a) it's tricky and (b) it involves a big corporate service provider that we can't control. But we'll have to see what is happening and get it straightened out.

Oh! The 3.5.0 is actually the most recent release, so you're on track there. There are a number of development branches at different levels of completion, and I was just suggesting to SWEET maintainers that it might be time to schedule the next release. To follow the details, you'd want to monitor the SWEET GitHub repository and its issues section, and/or the SWEET community mailing list described on the SWEET home page, and/or (if you're really interested) the #sweetontology channel in the ESIP slack workspace.

[giraygi]

Hello There!

We have a terminology Service published on https://service.tib.eu/ts4tib/index and we would like to add sweet ontology to our system. We need a plain text PURL of an ontology when we want to publish it so we are using https://raw.githubusercontent.com/ESIPFed/sweet/master/src/sweetAll.ttl for sweet. However, this file has several imports that should also be plain text for successful ingestion and these imports are not in the necessary format as you can see here from these examples:

• http://sweetontology.net/human ,
• http://sweetontology.net/humanAgriculture ,
• http://sweetontology.net/humanCommerce ,
• http://sweetontology.net/humanDecision ,

We will much appreciate if it is possible to correct these import like:

• https://raw.githubusercontent.com/ESIPFed/sweet/master/src/human.ttl ,
• https://raw.githubusercontent.com/ESIPFed/sweet/master/src/humanAgriculture.ttl ,
• https://raw.githubusercontent.com/ESIPFed/sweet/master/src/humanCommerce.ttl ,
• https://raw.githubusercontent.com/ESIPFed/sweet/master/src/humanDecision.ttl ,

in https://raw.githubusercontent.com/ESIPFed/sweet/master/src/sweetAll.ttl for consistency.

Cheers, Giray

[graybeal]

Yes, that goes to the same issue, it should work for your use case but the resolution issues in this ticket are (I believe) the problem. We have been doing some troubleshooting but need to get it resolved.

[dr-shorthair]

@giraygi - No - imports should use the identifier for the ontology or graph, not the 'file name' for just one particular representation of it.

You should be able to get the 'files' through HTTP content negotiation. Set Accept: text/turtle if that is what you want.

[brandonnodnarb]

Addressed by issue #150.