EPSO failed to process with status Error Rdf Labels

jvendetti commented 3 years ago

Received notification on the support list that EPSO isn't processing properly. Status on the summary page indicates that processing fails during label generation. Full stack trace from production log:

I, [2021-06-21T12:32:43.707538 #17470]  INFO -- : ["OWLAPI Java command: parsing finished successfully."]
I, [2021-06-21T12:32:43.707700 #17470]  INFO -- : ["Output size 1345338 in `/srv/ncbo/repository/EPSO/4/owlapi.xrdf`"]
I, [2021-06-21T12:32:44.148764 #17470]  INFO -- : ["Triples /srv/ncbo/repository/EPSO/4/owlapi.xrdf appended in <http://data.bioontology.org/ontologies/EPSO/submissions/4>"]
E, [2021-06-21T12:32:44.220770 #17470] ERROR -- : ["Exception: Rapper cannot parse turtle file at /tmp/data_triple_store20210621-17470-17dzhud: rapper: Parsing URI file:///tmp/data_triple_store20210621-17470-17dzhud with parser turtle
rapper: Serializing with serializer ntriples
rapper: Error - URI file:///tmp/data_triple_store20210621-17470-17dzhud:5 - syntax error at '<'
rapper: Parsing returned 4 triples

/srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/goo-b0a542f93804/lib/goo/sparql/client.rb:68:in `bnodes_filter_file'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/goo-b0a542f93804/lib/goo/sparql/client.rb:90:in `append_triples_no_bnodes'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/goo-b0a542f93804/lib/goo/sparql/client.rb:141:in `append_data_triples'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/goo-b0a542f93804/lib/goo/sparql/client.rb:153:in `append_triples'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:632:in `generate_missing_labels_pre'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:550:in `call'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:550:in `block (2 levels) in loop_classes'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:504:in `block in process_callbacks'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:500:in `delete_if'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:500:in `process_callbacks'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:549:in `block in loop_classes'
    /usr/local/rbenv/versions/2.6.6/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:531:in `loop_classes'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/bundler/gems/ontologies_linked_data-de150ab9388c/lib/ontologies_linked_data/models/ontology_submission.rb:1002:in `process_submission'
    /srv/ncbo/ncbo_cron/lib/ncbo_cron/ontology_submission_parser.rb:177:in `process_submission'
    /srv/ncbo/ncbo_cron/lib/ncbo_cron/ontology_submission_parser.rb:47:in `block in process_queue_submissions'
    /srv/ncbo/ncbo_cron/lib/ncbo_cron/ontology_submission_parser.rb:41:in `each'
    /srv/ncbo/ncbo_cron/lib/ncbo_cron/ontology_submission_parser.rb:41:in `process_queue_submissions'
    /srv/ncbo/ncbo_cron/bin/ncbo_cron:246:in `block (3 levels) in <main>'
    /srv/ncbo/ncbo_cron/lib/ncbo_cron/scheduler.rb:65:in `block (3 levels) in scheduled_locking_job'
    /srv/ncbo/ncbo_cron/lib/ncbo_cron/scheduler.rb:51:in `fork'
    /srv/ncbo/ncbo_cron/lib/ncbo_cron/scheduler.rb:51:in `block (2 levels) in scheduled_locking_job'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/gems/mlanett-redis-lock-0.2.7/lib/redis-lock.rb:43:in `lock'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/gems/mlanett-redis-lock-0.2.7/lib/redis-lock.rb:234:in `lock'
    /srv/ncbo/ncbo_cron/lib/ncbo_cron/scheduler.rb:50:in `block in scheduled_locking_job'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/gems/rufus-scheduler-2.0.24/lib/rufus/sc/jobs.rb:230:in `trigger_block'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/gems/rufus-scheduler-2.0.24/lib/rufus/sc/jobs.rb:204:in `block in trigger'
    /srv/ncbo/ncbo_cron/vendor/bundle/ruby/2.6.0/gems/rufus-scheduler-2.0.24/lib/rufus/sc/scheduler.rb:430:in `block in trigger_job'"]

jvendetti commented 3 years ago

Attempted the following during debugging:

Used Protege to load the ontology source file. Protege reports no parsing errors and successfully loads the file.
Uploaded the ontology to our staging environment. Processes without any errors in staging (submission ID is 3, see: https://stage.bioontology.org/ontologies/EPSO?p=classes).
Loaded the ontology in my local dev environment via a unit test. Processes without any errors locally.
Used the rapper command line utility to check the triples in the owlapi.xrdf file. No errors reported.
I noticed that they're using the owl:backwardCompatibleWith statement in the ontology source file, and it's declared in a way that seems different than what the specification calls for. I modified the statement to match the specification, and attempted to reprocess in production. Resulted in the same stack trace.

More specifics about the last bullet point - I changed this statement in the original file:

<owl:backwardCompatibleWith rdf:datatype="http://www.w3.org/2001/XMLSchema#string">1.0</owl:backwardCompatibleWith>

... to this:

<owl:backwardCompatibleWith rdf:resource="http://www.case.edu/EpSO.owl/1.0" />

... based on the example syntax in the specification I saw in this section.

graybeal commented 2 years ago

Updated support list notification:

We continue to experience parsing errors with the Epilepsy and Seizure Ontology (EpSO) OWL file.

The previous submission also experienced similar BioPortal parsing error documented as Issue#216:
https://github.com/ncbo/bioportal-project/issues/216.

The BioPortal issue tracker noted that the EpSO OWL file was correctly parsed in the BioPortal 
staging environment (https://stage.bioontology.org/ontologies/EPSO?p=classes).

The latest release of EpSO (version 2.1) OWL is experiencing same error "Error Rdf Labels").

We request your help in addressing this error at the earliest as we have received community 
feedback regarding their inability to visually browse EpSO in the BioPortal "Classes" and "Properties" 
tabs.

Points from today so far:

In the current submission 5 folder's log file, the same rapper issue as noted above occurred; no previous part of the parsing process reported an issue. (Note the parsing log file in the Admin page shows submission 4.)
I've uploaded v2.1 to staging to confirm that the problem still doesn't occur in staging.
I've tried reparsing in production to see if I could catch the temporary triples file that gets produced, to compare it to the data.triples file that is produced on staging. (Bit of a shot in the dark, that one.)
Code related to this issue is in https://github.com/ncbo/goo/blob/410d6aee244e758d34416c4cbad2965e60a33502/lib/goo/sparql/client.rb, particularly around line 56.

I'm waiting on staging and production to get through whatever they need to get through before seeing the results. Might not be tonight. >> Next morning: Same pattern as in June: Parses fine on staging, rapper fails on production.

jvendetti commented 2 years ago

The issue preventing label generation in production turned out to be incorrect advanced owl options specified by the end user in the new/edit submission form for the preferred name, synonym, and author properties:

Screen Shot 2021-10-15 at 6 01 54 PM

The above fields must contain a full property IRI (examples given in the help text) instead of the free text entered by the end user.

Uploaded a new submission in production with all of these fields left blank. The submission processed without errors and is fully available in BP now.

graybeal commented 2 years ago

emailed sender of original problem on support list.

jonquet commented 2 years ago

FYI: Since appliance 3.0, we also have a bunch of "local:" prefixes that are added here and there in our metadata properties by AgroPortal. They don't come form user edits. I assume this is a bug of the form.

graybeal commented 2 years ago

Mmm... hard to imagine how this form would cause that. Worth opening a new ticket with more precise details.

ncbo / bioportal-project

EPSO failed to process with status Error Rdf Labels #216