Documentation: Add example of how to generate template with role id.

[matentzn]

I am trying to run this template:

ID	Measurement definition
ID	EC EFO:0001444 and (RO:0002314 some %)
EFO:0004515	UBERON:0001015

using a query that does not involve an external ontology:

robot  template --template template.tsv --prefix "EFO: http://www.ebi.ac.uk/efo/EFO_" --prefix "RO: http://purl.obolibrary.org/obo/RO_" --prefix "UBERON: http://purl.obolibrary.org/obo/UBERON_" -o out.owl

But sed keeps failing on the expression EC EFO:0001444 and (RO:0002314 some %). (EC EFO:0001444 and % works file):

MANCHESTER PARSE ERROR the expression 'EFO:0001444 and (RO:0002314 some UBERON:0001015)' at row 3, column 3 in table "../templates/definemeasurements.tsv" cannot be parsed: encountered unknown 'some'
For details see: http://robot.obolibrary.org/template#manchester-parse-error
Use the -vvv option to show the stack trace.
Use the --help option to see usage information.

So basically, I would like to know how, or if, I can generate a template with a role if I don't have some input ontology to draw the labels from (i.e. to write an expression like: EFO:0001444 and ('inheres_in' some UBERON:0001015).

[jamesaoverton]

I spent 30 minutes on this, and I can't figure it out. It works fine if I use a label for RO:0002314. Prefixed names are also OK, but as soon as I put in some and a prefixed name, even the simple RO:0002314 some %, it fails.

ROBOT relies on the ManchesterOWLSyntaxClassExpressionParser. Does anybody know if that parser doesn't like prefixed names before some, or something?

[balhoff]

I think it has a lot to do with the OWLEntityChecker you have configured the expression parser with. I have had to provide a custom entity checker when trying to simultaneously handle labels and CURIES/IRIs.

[jamesaoverton]

Yes, but it's working fine with prefixed names for classes. Maybe the problem is in our checker for object properties. I messed with that but did not find a solution.

[matentzn]

Thanks both for looking into this! It seems to be failing on some sed command that is run prior to actually executing the template..

[jamesaoverton]

Our getOWLObjectProperty method seems fine to me. I don't understand this problem. At least there's an easy work-around: use a label.

[bjonnh]

Also it is complex to use labels if we are using terms that are generated from other templates…

[matentzn]

@ignazio1977 Sorry to bother you with this, but would you be able to look over this class: https://github.com/ontodev/robot/blob/master/robot-core/src/main/java/org/obolibrary/robot/QuotedEntityChecker.java

(I saw you have contributed to it at some point)

That it happily allows the Manchester syntax parser to parse curie class expressions (e.g. EFO:0001444 and %) but not CURIE role expressions (RO:0002314 some %)? If it takes you more than 5 min to spot, don't worry -> If I know what to do, I can also fix it myself.

[ignazio1977]

@matentzn well, six characters hardly counts as contribution :-P

Am I right in thinking a test for this would be (looking at QuotedEntityCheckerTest for inspiration):

ManchesterOWLSyntaxClassExpressionParser parser =
    new ManchesterOWLSyntaxClassExpressionParser(
        dataFactory, checker);
Assert.assertEquals(cls, parser.parse("GO:XXXX and (GO:part_of some %)"));

I'm going to give that a whirl and see if anything debuggable comes out.

[ignazio1977]

In the test I referenced, QuotedEntityChecker is using simple_parts.owl to initialise itself, and during parsing the Manchester parser is asking it if GO:part_of is a class name. The ontology declares GO:part_of as an object property, so the answer should have been no. However, it answers yes - apparently because of the IOHelper member.

[ignazio1977]

The implementation of getOWLClass:

/**
 * Find a class with the given name, or create one. Quotation marks will be removed if necessary.
 *
 * @param name the name of the entity to find
 * @return a class, or null
 */
@Override
public OWLClass getOWLClass(@Nonnull String name) {
  IRI iri = getIRI(classes, name);
  if (iri != null) {
    return dataFactory.getOWLClass(iri);
  }
  if (ioHelper != null) {
    iri = ioHelper.createIRI(name);
    if (iri != null) {
      return dataFactory.getOWLClass(iri);
    }
  }
  return null;
}

The problem is that OWLEntityChecker, by convention, should return null if values are not found - doesn't say so in its documentation, but that's how it gets used.

I'm going to try and NOT set an IOHelper in the test, see if that works.

[ignazio1977]

Feels likely that this seemed to work for classes simply because the parser checks for classes first, and so an implementation that always provides a class in request to a name seems to work.

[ignazio1977]

If the object property has a label in the ontology, and that label is used in the expression, everything seems to work fine. If instead an IRI, abbreviated with a prefix in the ontology or not, it fails because of the implementation above.

Feels like QuotedEntityChecker needs to be combined with an entity checker that will provide only entities that exist in the ontology and deals with namespaces. I can see it's a class used in quite many other classes, so I don't feel I can recommend easy fixes to this - I can't tell what's necessary for its current functionality and what can be changed to match the parsing needs.

IOHelper might be a good place to change things, but it's not an interface and it doesn't have methods specific to creating classes or property iris. Adding those, and calling them from QuotedEntityChecker, might be the way to go.

[matentzn]

@ignazio1977 thank you very very much for your super helpful analysis! This makes sense to me.. We will leave this ticket open and fix it when more pressure mounts - I think we have an idea now to go about it! Thousand thanks.

[balhoff]

I'm coming a bit late to this, but just wanted to mention that in my experiments upgrading ROBOT to OWL API 4.5.18, one of the failing tests relates to QuotedEntityChecker (@ignazio1977 already fixed the other https://github.com/owlcs/owlapi/issues/984). The problem relates to what Ignazio is talking about above with the issue of providing entities in a context-free situation. When trying to parse a class expression independent of an ontology, the current implementation will answer with an entity for all of Class, ObjectProperty, and DataProperty. In a real ontology only one of the latter two would exist with the same IRI. Currently if an entity checker is willing to create both an object property and a data property, class expression parsing fails (even if the IRI is being used only in a class position).

[ignazio1977]

@balhoff for the record, https://github.com/owlcs/owlapi/issues/984 is fixed and released in OWLAPI 4.5.19