OPIL types constraint

[rpgoldman]

(I'm afraid this is me banging on about documents again...)

The latest draft of the specification states the following:

All OPIL objects are given the most specific rdfType in the OPIL namespace (“http://bioprotocols.org/opil/v1#”) 13 that defines the type of the object. Namely, an object MUST have no more than one rdfType property in the 14 “http://bioprotocols.org/opil/v1#” namespace.

It is clear what you are trying to prohibit here -- multiple inheritance. But that isn't what this says, and what this says actually conflicts with RDF semantics. The RDF semantics (https://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#patterns-of-rdfs-entailment-informative) under "Patterns of RDFS entailment) gives the following inference rule (paraphrased by me):

if xxx is an rdfs:subClassOf yyy and zzz is an rdfs:instanceOf xxx then zzz is also rdfs:instanceOf yyy.

That means that the standard here would be contradicting the semantics.

You could achieve what you want by using DisjointClasses specification for your OPIL classes.

You could also state some condition on OPIL documents, but then we are back to me banging on about documents.

[jakebeal]

@rpgoldman Actually, I believe this constraint was trying to prohibit both multiple inheritance and also redundant statements regarding superclass. This was an inheritance from SBOL, which I believe set this in SBOL 2 due to some sort of technical limitation with the old XML format. So it may, in fact, be something that we can do away with and just focus on the multiple inheritance.

@bbartley Is it still a problem for us with the new OPIL libraries, or can we allow redundant statements about superclass identities?

[rpgoldman]

Great. Given the choice, I'd prefer that the multiple inheritance issue just be handled by using the existing OWL constructs in the spec.

Note that I think it's fine to handle it in any code using a special purpose enforcement; just that I think the declarative part of the spec should avoid doing so unless there's some reason it's essential.

[bbartley]

I think the factory methods in the OPIL library could be made to handle multiple inheritance with minimal headache. I can picture in my head how it would be implemented, though there is always a possibility of encountering the unexpected.

[jakebeal]

@rpgoldman Am I right in understanding your suggestion to be: "just don't build any classes that multiply inherit"? If so, I'm good with it. Do you want to set up a draft spec edit?

@bbartley Let's add a CI test for this in the future (low priority, though).

[rpgoldman]

Not sure I understand the question. If you wish to specify the single inheritance rule above, I think it would be sufficient to add disjoint class assertions into your Turtle spec, wouldn't it? That wouldn't enforce your "single most specific assertion" constraint, but that seems to be a separate issue, and may not be necessary.

[rpgoldman]

Something like this:

opil:ProtocolInterface rdf:type owl:Class ;
                       rdfs:subClassOf sbol:TopLevel ,
                                       owl:Thing ;
    rdfs:label "Protocol Interface" ;
    owl:disjointWith opil:ExperimentRequest .

?

[jakebeal]

Right, I forgot that we can do that. That seems straightforward enough.

[rpgoldman]

I'm assuming that means that the OWL/Turtle definition is somehow normative, not just informative...

[jakebeal]

@bbartley's code generates the Python classes directly from it the definition, so it's normative in that sense. I don't think this will actually make any difference for that code, though, since it is disjunctive by default.

[rpgoldman]

I was assuming that the OWL was part of the spec. Any reason not to have it be?

[jakebeal]

That's a good point, since we're generating the spec from it in any case. To prevent document size explosion, I'd lean toward having it be a supplementary appendix, though.

[rpgoldman]

An appendix sounds like a great idea. Consider using the OWL surface notation? Turtle is better than RDF/XML, but still not great...

[jakebeal]

One way or another, I'd want the appendix to be precisely the code that we're actually generating from, so that we minimize the potential for forking between spec and implementation.

[jakebeal]

Looking into this further, it looks like the multiple-types constraint was something that applied only in SBOL 2, and not SBOL 3 (which allows multiple non-conflicting rdf:type statements), so I can get rid of that offending line.