edamontology / edamxpathvalidator Goto Github PK

this maybe worth a look, re future QA/QC? cc @hmenager

I've found a few of these - have been removing as I go

narrowSynonym is not allowed in the Format subontology and should raise ERROR.

multiple concepts with the same namespace  have the same synonym 'Small molecule sketch' - 'Chemical structure image' (http://edamontology.org/data_1712) -> 'Chemical structure image' (http://edamontology.org/data_1712)

There's only concept listed so this doesn't compute :).

"Small molecular sketch" was a synonym in the (now-deprecated) Chemical structure sketch - which is replacdd by Chemical structure image, if that helps .

I could be missing something ...

In the soon-to-be-released Editors Guide:

Each subontology must not descend beyond a certain depth (see below).  Specifically, this means that each concept **MUST** have at least one path to root (*i.e.* `Topic <>`_, `Operation <>`_, `Data <>`_ or `Format <>`_ no deeper than indicated.   It's OK for a concept to have other paths to root that are deeper than this.
   2.1 **Topics** 3 levels deep max. *i.e.* *Topic* (root) -> Topic -> Subtopic -> Subsubtopic (leaves)
   2.2 **Operations** 6 levels deep max. 
   2.3 **Data** 4 levels deep max. 
   2.4 **Format** - 3 levels deep max. 

Not sure (I doubt) xpath can do this, but we need a check (raising an ERROR) in such cases.

Copied from edamontology/edamontology#170, which was in the wrong project.

@hmenager can you add checks that synonyms are unique, all types:
hasExactSynonym
hasNarrowSynonym
hasBroadSynonym

this will ensure we catch errors, e.g. edamontology/edamontology#131

Another comment from @joncison : This of course should be namespace aware.

see e.g. edamontology/edamontology#389 although there are other relevant fields, too

From talking to Simon Jupp in Austria last week, we should explore https://github.com/ontodev/robot for EDAM housekeeping including validation, diff, slim generation etc.

Validation is provided by the report function - we'd need to provide a list of SPARQL queries for the specific checks we'd want (@simonjupp - could you pls. send a link to some sample queries - which you showed me last week)

There's also a file structure-independent ontology diff and lots of other stuff

It could augment or perhaps eventually replace edamxpathvalidator

cc @hmenager

i.e. concepts with a single kid only, suggest to raise WARN

And for chains of singletons, suggest to raise ERROR - we don't want these and should fix, prob. by adding appropriate sibling concepts.

@hmenager could you please check this out:

• https://travis-ci.org/github/edamontology/edamontology/builds/769487739 says the unexpected < is in line 60486
• But it is in line 60485 according to edamontology/edamontology@3155563
• The column looks right (9)

Placeholders ("organisational classes") are currently annotated with <usageGuideline>Not recommended for annotation in bio.tools.</usageGuideline> (we need something better) and there shouldn't usually be chains of these in the EDAM Data subontology.

This can be clarified once the Editors Guide (http://edamontologydocs.readthedocs.io/en/latest/editors_guide.html) is more settled.

Raise WARN but we need to define exceptions according to the patters in EDAM where we know this is OK, e.g.

• Formats link to both Format (by type of data)(http://edamontology.org/format_2350) (or kids) and one of XML, Textual format etc.
• Operations can link to a top-level Operation in addition to others
• etc. (we need to enumerate exact rules)

Maybe raise ERROR when something has more than two parents - this points to a conceptual mess that needs cleaning up.

I'll firm this up once the Editors Guide (http://edamontologydocs.readthedocs.io/en/latest/editors_guide.html) is done.

This has to be first cleaned-up in EDAM itself, see edamontology/edamontology#418

• Every data_|format_|operation_|topic_ concept has data|format|operation|topic subset
• Everything in the mainline EDAM needs subset bio
• Subsets are encoded in a desired way, ideally (Semantic) Web-friendly. Needs some more experiments first...

Please add into the the synonyms multiplicity check:

• Primary labels

• Case-insensitivity

To avoid issues as edamontology/edamontology#244 and edamontology/edamontology#130

See build https://travis-ci.org/edamontology/edamontology/builds/410100632

(editted, sorry I haven't seen properly at first)

@hmenager
There was a correct ...is superclass of itself error message and the correct the class has two labels, which is forbidden in EDAM message, but:

• it had some weird things printed out around the assertion of the "two labels"
• ideally, the "two labels" should perhaps return an error message about "multiple" labels, not specifically just 2
  
  It is here:
  https://travis-ci.org/github/edamontology/edamontology/builds/769727535

Not urgent, but would be nice to fix for perfection.

Atm, the check is missing uniqueness including both label and a synonym. See bug edamontology/edamontology#741.

And there is no check of uniqueness between "sub-ontologies". Let's add a warning for now, to see what the situation is.

Plus please add related_term into the checks, just like any other synonym. (An even better solution would be inferring that it is a special case of a synonym, but I assume that might be possible only with an OWL/RDF reasoner(?))

Related note, not necessarily a part of this issue: I'm considering making file extensions searchable in BioPortal etc., by also defining them as a special case of a synonym. Not strictly related to that, but it'd be great for us to see whether the file extensions are unique or overlap somewhere (possibly also with a main label of a different format). But of course unlike other terms, these can overlap with the main label of the given format (e.g. label PDF and fileext pdf).

Another note: I assume the check if case-insensitive, i.e. the same term with just different capitalisation will fail the uniqueness check, right?

• Fail if the same term is used as the main label and as a synonym anywhere within the same "sub-ontology".
• Output a warning if the same term is used in multiple sub-ontologies, irrespective of whether it is the main label or a synonym.
• Include related_term into the check, fail if not unique.

Not a high priority, but very nice to convey professionalism, and easy via Unix ?

We'd need exceptions (to handle informatics jargon) including all known terms and synonyms already defined in EDAM.

Should raise WARN with action to update the exceptions dictionary

as asked in edamontology/edamontology#254