Andrea says:
It doesn't make sense to change the namespace for BioPAX for all the ontology at each release. Let's take for istance the NAME property. This is: http://www.biopax.org/release/biopax-level2.owl#NAME http://www.biopax.org/release/biopax-level1.owl#NAME But the identify the same property and any opeation that involves NAME involves the same semantics in the two versions. So it would be clearer (I think) if in the biopax2.owl file something has namespace for level 2 (new features) and something for level1. It is true that we can go around this with some reasoning... but I may want just to run a SPQRL query on an engine without reasoner.... And not only that. Asserting equality requires people to know which is the differrence between the two versione. This should be already provided to users by who defined the schema. I think we should take this approach, expecially for further releases. So level3 imports level2 and adds its statements in level3 namespace, and so on...
What I'm suggesting is to take the ID of entities ad properties stable. If the meaning doesn't change, don't change the URI. This is not just about namespaces, even if that's how it's evident now. If this is done, a tool defined for level x could still use a level 1 export without problems, as far as it finds the relations it needs.
Gary says:
>> Can't you just rename the namespace to Level2 when you import Level 1 data? > Not really, I mean you can from a practical point of view, but that's not very clean. > > I'll give you some reason: > > 1) I want to write a code that operates just on NAME (or something more complex, let's say that fetches INTERACTIONS). I don't need to know the actual or future version fo BioPAX or use a filter everytime from version to version. I just want to consider BioPAX-level1#NAME and that's all. > If this does not change, any tool written know will work (with limits) later. No need to upgrade at any version, unless new features are needed. > > 2) The meaning of the same property may change. Hence not everything seems easy but perhaps in level 5 :), Interaction will have a slightly different meaning from level 3, while something else may be the same and something else may be new. > Hence the process of just renaming thing would not be so straightforward, and best done at the ontolgy-definition level > > 3) Your policy works if older version of BioPAX are discontinued. That is, if once level2 is out, level1 is decalred invalid (ok transition time), but basically no responsability is taken from future use of level1... > If you want different versions to coexist theire relations should be stated clearly (i.e: namespaces). You make a very good point. The policy decision really dictates how this operates, though. In my mind, Level 2 would replace Level 1 with a transition time. However, in reality, the transition time depends on how people want to use BioPAX and is expected to be long, depending on how complete you consider a successful transition to be. For instance, some groups may be satisfied with level 1 and continue to make their data available in it forever. Other groups will always want to support the latest BioPAX version and do this within 6-12 months of release. If we look at how things are working with other pathway related standards, like PSI-MI or SBML that follow levels, you can see that the old versions never really go away. Though whether use of old versions is officially supported or not is another story. For instance, an old version could be "not supported", but then you would really have to provide converters to the new version (otherwise people would stop using the format). For instance, you could provide a script that updates the namespace. It sounds like we also need more experience using RDF tools, like SPARQL, that make use of the namespace and what requirements those tools have in order to make proper decisions on these points. Chris Lemer suggested the import mechanism that you describe and that makes sense to me, but how does it handle changes to classes? E.g. if you want Level 3 to not have the sequenceParticipant class anymore, how can you say this using the import mechanism? The other option is using the same namespace for all versions of BioPAX, but this would make it harder for people to know what version they are using. Right now, they can just look at the namespace. Maybe there is another way of coding the version in OWL. In XML Schema it is easy and both PSI-MI and SBML define XML attributes for the level and version number, but defining XML attributes is not possible in OWL.
Andrea replies:
Well, first I'm not taling abot "import" but about keeping URI for classes and properties consistent. So it would work this way: www.biopax.com/release/biopax-level2.owl defines whatever it wants, but will use bp1:interaction, bp1:control ... This doesn't mean we are importing an ontology, just we are resuing those names for classes or properties that didn't change. This could make much easier to make tools and files versione in armony. the import mechanism of course import an ontology, so that's part of the ontology you are dealing with. It's hard to take away pieces of it :) Anyway, you can declare deprecated methods, but that's not the same thing. This doesn't mean than from biopax1 to 2 you conld'n just include the ontology.... If you think about it, to include the ontology means to read its statements and add them ton your model. Maybe you need all of them, maybe not :) > The other option is using the same namespace for all versions of BioPAX, but this would make it harder for people to know what version they are using. Right now, they can just look at the namespace. Maybe there is another way of coding the version in OWL. In XML Schema it is easy and both PSI-MI and SBML define XML attributes for the level and version number, but defining XML attributes is not possible in OWL. In BioPAX you are using owl, rdf, rdfs, xsd... lot of namespaces without importing them. Why not bp1 ? The file would still be called biopax-level2. And anyway you have a lot of annotation properties you can use to declare: owl:versionInfo owl:priorVersion owl:backwardCompatibleWith owl:incompatibleWith We may add soome of them to the heders of 1 & 2 one of these days...
Gary:
I agree that it would be nice to label each new property with the level of BioPAX that it was defined in. My worry is that only certain software systems, like SPARQL have this as a requirement and that it adds complexity for users who aren't using these tools (e.g. users of Jena) - who then may more easily make mistakes with this aspect when creating BioPAX files. Maybe it's not such a big issue - would the difference between current and what you're proposing be the following (not a real example - just look at the namespaces defined on the XML elements)?
<bp:bioSource rdf:ID="bioSource33">
<bp:NAME rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Escherichia coli</bp:NAME>
<bp:TAXON-XREF>
<bp:unificationXref rdf:ID="unificationXref34">
<bp:ID>562</bp:ID>
<bp:DB rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>taxon</bp:DB>
</bp:unificationXref>
</bp:TAXON-XREF>
</bp:bioSource>
vs.
<bp1:bioSource rdf:ID="bioSource33">
<bp1:NAME rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Escherichia coli</bp1:NAME>
<bp2:TAXON-XREF>
<bp2:unificationXref rdf:ID="unificationXref34">
<bp2:ID>562</bp2:ID>
<bp2:DB rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>taxon</bp2:DB>
</bp2:unificationXref>
</bp2:TAXON-XREF>
</bp1:bioSource>
Open issues
This is an important issue and we need to deal with it. I think we need to resolve these issues before we can make a good decision on this (Gary)
What is the recommendation from an OWL expert on how namespaces should be used?
Can we gather requirements of various tools for this issue? This problem crops up with the use of at least SPARQL and probably other RDF and OWL query languages, but many other tools don't complain. Who has experience in this area?
What is the best way to keep track of the version of BioPAX that a given BioPAX document is adhering to?
What would BioPAX level 2 look like if we implemented a new namespace only for new classes and properties? What would a BioPAX document that imports this ontology look like?
Some comment (Andrea)
(2) I don't think this problem is tool related. It didn't popup with other tools just becouse there aren't tools addressing the proper level of generality. I think any tools concerned with the property "NAME" for istance, will need to univoquely define it across the versions, and independently of the versions, as far as NAME does not change its meaning.
(4) I don't think there is particular problem in this. Will look like any owl documents, that uses different namespaces. I guess for istance and ontology file will include BioPAXlevel2.owl, and in the BioPAXleel2.owl, some entity will be in level1 namespace, ome in level2 namespace.