search

SynBioDex / libSBOLj

Java Library for Synthetic Biology Open Language (SBOL)
Apache License 2.0
37 stars 24 forks source link

Interaction/Participation only recognize some recommended SBO terms #563

Closed jakebeal closed 5 years ago

jakebeal commented 5 years ago

The interaction types and participation roles are specified as recommended to come from certain branches of SBO (occurring entity relationship and participant role, respectively).

libSBOLj, however, will raise best-practices violations (sbol-11905, sbol-12007) for any term that is not in Table 13 or Table 14 of the specification. This omits many terms in these branches such as containment relations, which is the one that's triggering the violations for us right now.

cjmyers commented 5 years ago

That is not actually correct. It will accept all terms that are descendants of those branches. See code here starting about line 1162:

https://github.com/SynBioDex/libSBOLj/blob/master/core2/src/main/java/org/sbolstandard/core2/SBOLValidate.java

Are you adding more than one SBO term? Because these rules actually state that there must be exactly one term from SBO. This is perhaps why you are getting this message.

On Feb 26, 2019, at 9:39 AM, Jacob Beal notifications@github.com wrote:

The interaction types and participation roles are specified as recommended to come from certain branches of SBO (occurring entity relationship and participant role, respectively).

libSBOLj, however, will raise best-practices violations (sbol-11905, sbol-12007) for any term that is not in Table 13 or Table 14 of the specification. This omits many terms in these branches such as containment relations, which is the one that's triggering the violations for us right now.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SynBioDex/libSBOLj/issues/563, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD98S_XQzLwG2sAaBy7Lob5JbW2_huks5vRWNJgaJpZM4bSmvS.

jakebeal commented 5 years ago

I'm pretty sure we're using only one SBO term.

Can you please try setting up an interaction with these and see if it signals errors for you?

cjmyers commented 5 years ago

Ah, I see the issue, you are using the wrong URI prefix, it should be identifiers.org http://identifiers.org/, namely:

http://identifiers.org/biomodels.sbo/ http://identifiers.org/biomodels.sbo/

On Feb 27, 2019, at 3:52 AM, Jacob Beal notifications@github.com wrote:

I'm pretty sure we're using only one SBO term.

Can you please try setting up an interaction with these and see if it signals errors for you?

Interaction type: http://www.ebi.ac.uk/sbo/main/SBO:0000469 http://www.ebi.ac.uk/sbo/main/SBO:0000469 Participant 1 role: http://www.ebi.ac.uk/sbo/main/SBO:0000289 http://www.ebi.ac.uk/sbo/main/SBO:0000289 Participant 2 role: http://www.ebi.ac.uk/sbo/main/SBO:0000664 http://www.ebi.ac.uk/sbo/main/SBO:0000664 — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SynBioDex/libSBOLj/issues/563#issuecomment-467816716, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD96UdTUnbA5YrZq1Rcqp1NNB5-tCkks5vRmNzgaJpZM4bSmvS.

jakebeal commented 5 years ago

According to the spec, it is not wrong: in fact, the spec directs you to http://www.ebi.ac.uk/sbo/main/

Since both are valid URIs for the same ontology, if the identifiers.org is preferred:

  1. the spec should say that, and
  2. the library ought to detect and report that preference, rather than simply saying it is wrong.
cjmyers commented 5 years ago

The link to the definitions is to the EBI site as it is easier to navigate. However, we agreed at SBOL meetings that we would always use identifiers.org. Indeed, the table shows them in this form. I believe you should open an issue on the specification issue tracker that we should clarity that this IS a best practice error. This is not really a preference, it is a big problem to use two or more URIs for the same thing since it will greatly complicate software, especially that which relies on SPARQL queries as each would need to be explicitly listed in your queries. My take is this is indeed a best practice problem with the file and the error message is correct. It was sufficient for you to realize you had a problem.

jakebeal commented 5 years ago

Since the answer to 1 is yes, I'll open the specification issue.

However, I still maintain that the error message needs to be improved, because it led us directly to conclude that the problem was with the library, not with our URIs.

cjmyers commented 5 years ago

Perhaps, but all validation error messages are pulled directly from the specification. We would need a new validation error which is says explicitly that this URI is not preferred. We could add such a rule, then we would implement the check for it. So, I would say this even is a specification issue.