sbml-annot — SBML L3 annotations discussion list

Re: [sbml-annot] OWL2 Vs RDF

[Nicolas Le N. <le...@eb...>]

Should-we have a vote?

On 09/05/11 11:20, Neil Swainston wrote:
> Hi all,
>
> I agree with all of Nicolas's points bar one:
>
>>> OWL2
>>> ====
>>>
>>> Cons: We may scare off developers.
>
> While we should be very careful not to scare off developers, I think that
> if we are sensible about how we generate a libSBML extension for annot, we
> can "hide" much of the OWL2 (or RDF) complexity behind a simple API. In
> either case (OWL2 or RDF) we are essentially generating triples, so at the
> very basic level, adding some methods to SBase along the lines of...
>
> addStatement( String predicate, String object )
>
> ...should hide much of the complexity from the developer, whether we go
> with OWL2 or RDF. This could be extended to support Reification, perhaps
> hook into MIRIAM resources, etc.
>
> Also, we would like to provide a more expressive interface for those who
> know what they are doing, such that they can just get/set a block of
> annotation if they'd like.
>
> My main question is, what do we do now? At Harmony, myself, Sarah and Frank
> were taking about generating an API to support our current proposal. While
> I'm happy and interested to do this, I don't want to until we've nailed
> down more fundamental questions like OWL2 vs RDF.
>
> Cheers,
>
> Neil.
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
>
> On 9 May 2011, at 11:05, Nicolas Le Novère wrote:
>
>> On 22/04/11 15:58, Neil Swainston wrote:
>>
>>> A.d. This troubles me a little. By going down the RDF route (rather than
>>> OWL/OWL2) are we preventing ourselves from making negative statements in
>>> future? I personally don't fancy introducing a second annotation method
>>> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team
>>> Annot?
>>
>> This is IMHO one of the most important discussions we need to have. There
>> are pros and cons on both sides:
>>
>> RDF
>> ===
>>
>> Cons: limited expressiveness. It does not seems this is likely to change.
>> Pros: large support in the semantic web, coherent with SBML core, support
>> by the SBML community, and in development by the CellML and NeuroML
>> communities
>>
>> OWL2
>> ====
>>
>> Cons: Not widely supported yet, different from what we do in SBML core. We
>> may scare off developers.
>> Pros: More expressive. BioPAX is in OWL2.
>>
>> We can also "port" some of OWL's structures into SBML's RDF.
>>
>> I do not think we are talking about a year's time as Neil wrote. Whatever
>> we choose is a commitment for a few years. This is not necessarily a bad
>> thing. The whole linked data is evolving fast at the moment.
>>
>> --
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today. Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] OWL2 Vs RDF

[Neil S. <nei...@ma...>]

Hi all,

I agree with all of Nicolas's points bar one:

>> OWL2
>> ====
>> 
>> Cons:  We may scare off developers.


While we should be very careful not to scare off developers, I think that if we are sensible about how we generate a libSBML extension for annot, we can "hide" much of the OWL2 (or RDF) complexity behind a simple API. In either case (OWL2 or RDF) we are essentially generating triples, so at the very basic level, adding some methods to SBase along the lines of...

addStatement( String predicate, String object )

...should hide much of the complexity from the developer, whether we go with OWL2 or RDF. This could be extended to support Reification, perhaps hook into MIRIAM resources, etc.

Also,  we would like to provide a more expressive interface for those who know what they are doing, such that they can just get/set a block of annotation if they'd like.

My main question is, what do we do now? At Harmony, myself, Sarah and Frank were taking about generating an API to support our current proposal. While I'm happy and interested to do this, I don't want to until we've nailed down more fundamental questions like OWL2 vs RDF.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 9 May 2011, at 11:05, Nicolas Le Novère wrote:

> On 22/04/11 15:58, Neil Swainston wrote:
> 
>> A.d. This troubles me a little. By going down the RDF route (rather than
>> OWL/OWL2) are we preventing ourselves from making negative statements in
>> future? I personally don't fancy introducing a second annotation method
>> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team
>> Annot?
> 
> This is IMHO one of the most important discussions we need to have. There 
> are pros and cons on both sides:
> 
> RDF
> ===
> 
> Cons: limited expressiveness. It does not seems this is likely to change.
> Pros: large support in the semantic web, coherent with SBML core, support 
> by the SBML community, and in development by the CellML and NeuroML communities
> 
> OWL2
> ====
> 
> Cons: Not widely supported yet, different from what we do in SBML core. We 
> may scare off developers.
> Pros: More expressive. BioPAX is in OWL2.
> 
> We can also "port" some of OWL's structures into SBML's RDF.
> 
> I do not think we are talking about a year's time as Neil wrote. Whatever 
> we choose is a commitment for a few years. This is not necessarily a bad 
> thing. The whole linked data is evolving fast at the moment.
> 
> -- 
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
> 
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network 
> management toolset available today.  Delivers lowest initial 
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

[sbml-annot] OWL2 Vs RDF

[Nicolas Le N. <le...@eb...>]

On 22/04/11 15:58, Neil Swainston wrote:

> A.d. This troubles me a little. By going down the RDF route (rather than
> OWL/OWL2) are we preventing ourselves from making negative statements in
> future? I personally don't fancy introducing a second annotation method
> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team
> Annot?

This is IMHO one of the most important discussions we need to have. There 
are pros and cons on both sides:

RDF
===

Cons: limited expressiveness. It does not seems this is likely to change.
Pros: large support in the semantic web, coherent with SBML core, support 
by the SBML community, and in development by the CellML and NeuroML communities

OWL2
====

Cons: Not widely supported yet, different from what we do in SBML core. We 
may scare off developers.
Pros: More expressive. BioPAX is in OWL2.

We can also "port" some of OWL's structures into SBML's RDF.

I do not think we are talking about a year's time as Neil wrote. Whatever 
we choose is a commitment for a few years. This is not necessarily a bad 
thing. The whole linked data is evolving fast at the moment.

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] SBML Level 3 Package Proposal: Annotation

[Stefan H. <sh...@vb...>]

Hello All,

On 4/22/11 11:56 AM, Michel Dumontier wrote:
 >> C.1. XPath. I don't get why the method of referring to attributes 
should be
 >> >  any less unique than referring to elements themselves. In both 
cases, they
 >> >  are reliant upon the meta_id being unique. I'd have thought that 
the problem
 >> >  of non-uniqueness would exist for all of these annotations, 
irrespective of
 >> >  whether they are to attributes or elements. (?)
 >> >
 >> >  do you think that your meta_id is unique across all models that 
will ever
 > be made?  You might consider providing a unique identifier generator.
 >
 >

As far as my understanding goes we have the following situation:
1) the metaids are guaranteed to be unique within one XML document since 
they are derived from an XMLId.
2) It is possible to uniquely identify any object which has a metaid in 
another document, e.g. rdf:about="file://....#metaid

 >> > C.2. Reification. At first glance this looks to be a similar
 >> > situation to the one above - that IDs may be non-unique across
 >> >  documents. I must confess that I've only considered the case that
 >> > an SBML document is self-contained, and we can therefore ensure
 >> > uniqueness for both meta_ids and rdf:IDs. Having said that, I
 >> > thought that reification was an established practice? Is it not
 >> >  widely used in the real world?
 > >
 > > it cannot be used in the linked data world - because there's no way
 > > to reliably make reference to such nodes.

You are correct that reification may create statements about non 
existing tripples in an rdf graph, i.e., meaningless statements. However 
I do not understand why this is a problem. Especially if we do not use 
an rdf:id as a statement identifier. I prefer the following explicit 
syntax to refer to a statement:

  R rdf:type rdf:Statement
  R rdf:subject S
  R rdf:predicate P
  R rdf:object O

In this case even if the statement is no longer present. The reification 
is still valid. In addition with the above facts about the metaids we 
can unambiguously make statements about statements in other documents.

Thanks,
Stefan


-- 
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax:   (540) 231-2606
Email: sh...@vb...

Re: [sbml-annot] SBML Level 3 Package Proposal: Annotation

[Michel D. <mic...@gm...>]

Hi Neil,

On Fri, Apr 22, 2011 at 10:58 AM, Neil Swainston <
nei...@ma...> wrote:

> Hi Michel,
>
> Thanks very much for this. Really appreciate your input. I'll go through
> each point in turn:
>
> A.a. From my point of view, I'd be happy to remove the emphasis on use of
> containers and collections in the document. The consideration of these maybe
> is a hangover from the SBML Level 2 annotation "format" which insisted that
> Bags were used. (No idea why - this is presumably just a quirk of history).
> If, as you say, that containers and collections are rarely, if ever used in
> the "real world" of hardcore RDF, I'd be in favour of pretty much stripping
> them from the document. That's not to say forbidding them in Level 3 Annot
> (where anything should go if users want - I'm a libertarian) but certainly
> not encouraging their use.
>
> A.b. Similar to above, I guess, in terms of relying more on making
> unconnected statements, independently of collections/containers. The two
> statements (hasPart) hold if one or the other is absent or not.
>
> A.c. This is a historical (and ambiguous/nonsensical) example from Level 2,
> which we're trying to avoid in L3.
>
> A.d. This troubles me a little. By going down the RDF route (rather than
> OWL/OWL2) are we preventing ourselves from making negative statements in
> future? I personally don't fancy introducing a second annotation method
> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team
> Annot?
>
> OWL maps to some parts of RDF.  OWL provides language to express certain
kinds of knowledge such that their semantics can be interpreted by reasoners
that know what to do with them (e.g. OWL reasoners). OWL can be serialized
in RDF/XML, and therefore shares a common syntax with RDF.

The major challenge is moving from so-called linked data to axioms in an
ontology.  these are both syntactically different and also have different
semantics. You saw from my presentation
http://www.slideshare.net/micheldumontier/harmony-2011-formalization-of-sbml-models-as-owl-ontologies

that going into a more formal language (OWL) means that you can
i) check the consistency of knowledge
ii) compute subsumption
iii) discover knowledge through query answering over inferred knowledge

Because there is prior work here, you may want to develop this aspect
collaboratively, or at least fully knowing how the representation
complements existing knowledge or offers a compelling advantage in terms of
knowledge representation.


> B.1. Hmmm. The impression that I got was that, in RDF terms, predicates
> should be thought of in the same way as Java/C++/OO classes, given that they
> can have properties, inherit from one another, etc. Also, I got hung-up on
> the "SUBJECT has PREDICATE whose value is OBJECT" mantra, which states that
> the predicate is a property of the subject. In this context, X has
> IS_PART_OF whose value is Y doesn't make a lot of sense. Any comments on
> this?
>
>
this is mostly a legacy of ER diagrams where nouns were used as predicates
and tools added the verb 'has' or 'is ... of'. but there's no need for this.
 so

'x' 'is a part of' 'Y'

is a statement about 'x', which relates 'y' through 'is a part of', and is
fairly natural



> B.2. New predicates. Michel, I guess you already have terms in your
> ontology to represent these concepts? Rather than map a new set of
> predicates to your ontology, would now be a good time to look into just
> adopting what you already have?
>

Our view, as per Bio2RDF and open linked data, is that you should first
think about the entities of interest in your domain and the relations that
hold between them. Our ontology may serve as a scaffold to map these
specific relations to our more general ones.  You can certainly consider
using them directly, but we can also create logical mappings which allow you
to query across your data and all the data and services that are expressed
using SIO.



>
> C.1. XPath. I don't get why the method of referring to attributes should be
> any less unique than referring to elements themselves. In both cases, they
> are reliant upon the meta_id being unique. I'd have thought that the problem
> of non-uniqueness would exist for all of these annotations, irrespective of
> whether they are to attributes or elements. (?)
>
> do you think that your meta_id is unique across all models that will ever
be made?  You might consider providing a unique identifier generator.


> C.2. Reification. At first glance this looks to be a similar situation to
> the one above - that IDs may be non-unique across documents. I must confess
> that I've only considered the case that an SBML document is self-contained,
> and we can therefore ensure uniqueness for both meta_ids and rdf:IDs. Having
> said that, I thought that reification was an established practice? Is it not
> widely used in the real world?
>
> it cannot be used in the linked data world - because there's no way to
reliably make reference to such nodes.



> C.3. Can certainly look at the provenance ontology. I didn't understand the
> point regarding MIRIAM uris in the context of this. Could you give an
> example?
>
MIRIAM URIs as a means to generate unique identifiers for your models and/or
corresponding RDF annotation.



>
>
> I'll take a look at n-ary relations later - want to listen to the talks!
>
> I was struck by the distinction that you make between simply "tagging"
> concepts with CHEBI terms (for instance), as we do now, and producing
> annotations that can be utilised in more-formal reasoning. I personally will
> have to give this some more thought (and do more reading), but as I say, I'd
> rather support both simple tagging and reasoning in whatever we end up
> implementing.
>

yup, i think the tagging is agnostic of what the tag means - we can
disambiguate this to some extent, but your annotations are getting more
sophisticated.  Otherwise, the simplest implementation is a simple s,p,o
triple, and we can generate the OWL axioms from this.

Best,

m.


>
> Cheers,
>
> Neil.
>
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
>
> On 22 Apr 2011, at 09:48, Michel Dumontier wrote:
>
> Hi,
> Here are my comments regarding the SBML Level 3 Package proposal on
> annotation
> http://precedings.nature.com/documents/5610/version/1
>
> A. syntax and semantics of containers and collections
> Containers (bag, seq, alt) specify *groups* those in which their members
> may
> be ordered (seq) or unordered (bag, alt), or that contain duplicates (bag,
> seq) or is unique (alt).
> Collections (list) specify *groups* that can only contain the specified
> members.
>
> So there are several criticisms in using this constructs for the SBML
> annotations.
> 0 - the relation is from the species to a group which has particular
> members. I don't believe this is really desireable because it both dilutes
> and confuses the semantics of the relation.
> 1 - these constructs are seldom (if at all) used in the linked data
> community. Their semantics are more amenable to being used to list items in
> forms or surveys, where you actually want to order list items (e.g. HTML
> ordered/unordered lists), or restrict the value choices (e.g. radio
> buttons).
> 2 - these constructs requires one to create a different kind of SPARQL
> query
> to get at the values. instead of asking for the value of subject, predicate
> or subject-predicate expression (e.g. :a :p ?y), one now has to ask for the
> member of a collection (e.g. using Jena :a :p [ rdfs:member ?y], or with no
> application-specific short cut it gets significantly more ugly).
> 3 - these constructs are not supported in OWL (they are elements of the
> syntax of the language, but not part of what modelers use)
> 4 - I don't think the cited examples are valid in the context of the stated
> intent.
> a. Figure 6 shows two annotations linked through the "is" property to a
> glucose species. Given the intended semantics of "is" and that ChEBI and
> KEGG are two different resources, it seems to be that what is actually
> meant
> is that this species corresponds to (represents) the physical entities
> denoted by the ChEBI and KEGG identifiers, and that these should not be
> disjoint types.  I really see two distinct statements (in turtle format).
> :meta_glc bqbiol:is <urn:miriam:obo.chebi:CHEBI%3417234>
> :meta_glc bqbiol:is <urn:miriam:kegg.compound:C00234>
>
> b. Figure 7 shows the annotation of a calcium-calmodulin complex, in which
> the intent is to state that the complex is composed of calcium and that the
> complex is composed of calmodulin. the mereological nature of this
> statement
> basically doesn't require one to state either a conjunction (which would
> imply that the value is a member of both types) or disjunction (which would
> imply that the value is a member of one or the other types), but rather
> should be treated as a set of separate statements
>
> :cacam bqbiol:hasPart <urn:miriam:uniprot:P62158>
> :cacam bqbiol:hasPart <urn:miriam:kegg.compound:C00076>
>
> c. Figure 8 shows how bag elements can be separated, but i question the
> need
> to have bag involved at any level here.
>
> d. negative statements - the syntax for negative object assertions are
> provided by OWL2
>
>
> B. predicates and qualifiers
>
> 1. "To satisfy RDF, predicates should be nouns,"
> knowledge representation languages such as RDF/OWL are agnostic when it
> comes to the choice of the characters in a symbol, safe those that are
> reserved as elements of the language. The naming of entities is entirely up
> to the modeler and has no bearing on the interpretation by a tool over the
> data. Thus, the choice of nouns or verbs are entirely within the control of
> the modeler. IMHO, verb predicates are more accurate in the nature of the
> relation, and improve the quality of tools that want to work with
> (controlled) natural language expressions. Ultimately this is a style
> choice.
>
> 2. the list of new predicates provided in the appendix are not described,
> and hence I cannot offer my opinion on them as to their merit or whether
> they are instrinsically different relations. However, by looking at the
> names themselves, i doubt very much that this is the direction you actually
> benefit from.
>
> C. Provenance
> 1. Statements about attributes
> While i find the use of xpath expressions to identify parts of the XML
> element that one wants to refer to as being very necessary and interesting,
> I fear that the name may not be sufficiently unique and that in a large RDF
> graph of such annotations, they would get jumbled up.
>
> 2. Statements about statements
> The problem with the reification plan is that the assignment of internal
> identifiers (rdf:id) is never guaranteed to remain the same, and as such
> cannot be considered as linkable data. Thus annotations will necessarily
> have to be created and maintained in that same file, and this will preclude
> others from commenting on annotations. Another solution is to consider
> OWL2's annotation object, which is strongly typed to reify statements, and
> may be assigned a stable URI. Additional semantics of annotation
>
> 3. Options: In both 1 and 2 above, i might suggest the use of miriam
> identifiers for both models and their components. I might also suggest to
> investigate the provenance ontology [
> http://trdf.sourceforge.net/provenance/ns.html]
>
>
>
> 3. n-ary relations (referred to as non-binary relations)
> n-ary relations are problematic for a large number of reasons including
> restriction on the number and type of relations to the decidability of
> reasoning. For these and other reasons, OWL2 maintains only binary object
> relations (and hence the created annotations would be incompatible with an
> OWL knowledge base), which then forces one to adopt more principled/modular
> patterns in the design of expressive and reason-able ontologies. Thus, I
> would recommend to think about the nature of the entities and the relations
> that hold between them.
>
> The use case is "Hexokinase 2 is modified by phosphoserine in position
> 158".
> First, the use case is badly worded, and I think it refers to either :
> 1 - there exists a variant of hexokinase 2 which contains a phosphorylated
> serine at position 158  (because surely hexokinase 2 and modified
> hexokinase
> 2 are two different kinds)
> 2 - there exists a process which phosphorylates hexokinase 2's serine at
> position 158 (and hence there is a regular hexokinase + phosphate as input
> and a phosphorylated hexokinase as output).
>
> In order to express (1), we might want to state (in turtle syntax)
> :hexokinase-2-PS158
>   rdf:type :protein;
>   :is-variant-of :hexokinase-2;
>   :has-proper-part [
>        rdf:type :phosphoserine;
>       :has-attribute [
>            rdf:type :sequence-position;
>           :has-value "158"^^xsd:int]] .
>
> in this way, we maintain the use of binary relations, and we now have new
> types which have relations that are appropriate to them.  Thus modelling
> can
> be better controlled, and evolution of new types with additional
> restrictions follow along the design pattern. This pattern follows what we
> are doing with the Semanticscience Integrated Ontology (SIO) -
> http://code.google.com/p/semanticscience/wiki/SIO
>
>
> Hope the above is helpful in refining the proposal in so that it reflects
> more powerful design patterns for the RDF/OWL Semantic Web languages.
>
> m.
>
>
> --
> Michel Dumontier
> Associate Professor of Bioinformatics
> Carleton University
> http://dumontierlab.com
>
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been
> demonstrated beyond question. Learn why your peers are replacing JEE
> containers with lightweight application servers - and what you can gain
> from the move. http://p.sf.net/sfu/vmware-sfemails
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>
>
>


-- 
Michel Dumontier
Associate Professor of Bioinformatics
Carleton University
http://dumontierlab.com

Re: [sbml-annot] SBML Level 3 Package Proposal: Annotation

[Neil S. <nei...@ma...>]

Hi Michel,

Thanks very much for this. Really appreciate your input. I'll go through each point in turn:

A.a. From my point of view, I'd be happy to remove the emphasis on use of containers and collections in the document. The consideration of these maybe is a hangover from the SBML Level 2 annotation "format" which insisted that Bags were used. (No idea why - this is presumably just a quirk of history). If, as you say, that containers and collections are rarely, if ever used in the "real world" of hardcore RDF, I'd be in favour of pretty much stripping them from the document. That's not to say forbidding them in Level 3 Annot (where anything should go if users want - I'm a libertarian) but certainly not encouraging their use.

A.b. Similar to above, I guess, in terms of relying more on making unconnected statements, independently of collections/containers. The two statements (hasPart) hold if one or the other is absent or not.

A.c. This is a historical (and ambiguous/nonsensical) example from Level 2, which we're trying to avoid in L3.

A.d. This troubles me a little. By going down the RDF route (rather than OWL/OWL2) are we preventing ourselves from making negative statements in future? I personally don't fancy introducing a second annotation method based on RDF only to ditch it for OWL in a year's time. Thoughts, Team Annot?

B.1. Hmmm. The impression that I got was that, in RDF terms, predicates should be thought of in the same way as Java/C++/OO classes, given that they can have properties, inherit from one another, etc. Also, I got hung-up on the "SUBJECT has PREDICATE whose value is OBJECT" mantra, which states that the predicate is a property of the subject. In this context, X has IS_PART_OF whose value is Y doesn't make a lot of sense. Any comments on this?

B.2. New predicates. Michel, I guess you already have terms in your ontology to represent these concepts? Rather than map a new set of predicates to your ontology, would now be a good time to look into just adopting what you already have?

C.1. XPath. I don't get why the method of referring to attributes should be any less unique than referring to elements themselves. In both cases, they are reliant upon the meta_id being unique. I'd have thought that the problem of non-uniqueness would exist for all of these annotations, irrespective of whether they are to attributes or elements. (?)

C.2. Reification. At first glance this looks to be a similar situation to the one above - that IDs may be non-unique across documents. I must confess that I've only considered the case that an SBML document is self-contained, and we can therefore ensure uniqueness for both meta_ids and rdf:IDs. Having said that, I thought that reification was an established practice? Is it not widely used in the real world?

C.3. Can certainly look at the provenance ontology. I didn't understand the point regarding MIRIAM uris in the context of this. Could you give an example?


I'll take a look at n-ary relations later - want to listen to the talks!

I was struck by the distinction that you make between simply "tagging" concepts with CHEBI terms (for instance), as we do now, and producing annotations that can be utilised in more-formal reasoning. I personally will have to give this some more thought (and do more reading), but as I say, I'd rather support both simple tagging and reasoning in whatever we end up implementing.

Cheers,

Neil.


Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 22 Apr 2011, at 09:48, Michel Dumontier wrote:

> Hi,
> Here are my comments regarding the SBML Level 3 Package proposal on
> annotation
> http://precedings.nature.com/documents/5610/version/1
> 
> A. syntax and semantics of containers and collections
> Containers (bag, seq, alt) specify *groups* those in which their members may
> be ordered (seq) or unordered (bag, alt), or that contain duplicates (bag,
> seq) or is unique (alt).
> Collections (list) specify *groups* that can only contain the specified
> members.
> 
> So there are several criticisms in using this constructs for the SBML
> annotations.
> 0 - the relation is from the species to a group which has particular
> members. I don't believe this is really desireable because it both dilutes
> and confuses the semantics of the relation.
> 1 - these constructs are seldom (if at all) used in the linked data
> community. Their semantics are more amenable to being used to list items in
> forms or surveys, where you actually want to order list items (e.g. HTML
> ordered/unordered lists), or restrict the value choices (e.g. radio
> buttons).
> 2 - these constructs requires one to create a different kind of SPARQL query
> to get at the values. instead of asking for the value of subject, predicate
> or subject-predicate expression (e.g. :a :p ?y), one now has to ask for the
> member of a collection (e.g. using Jena :a :p [ rdfs:member ?y], or with no
> application-specific short cut it gets significantly more ugly).
> 3 - these constructs are not supported in OWL (they are elements of the
> syntax of the language, but not part of what modelers use)
> 4 - I don't think the cited examples are valid in the context of the stated
> intent.
> a. Figure 6 shows two annotations linked through the "is" property to a
> glucose species. Given the intended semantics of "is" and that ChEBI and
> KEGG are two different resources, it seems to be that what is actually meant
> is that this species corresponds to (represents) the physical entities
> denoted by the ChEBI and KEGG identifiers, and that these should not be
> disjoint types.  I really see two distinct statements (in turtle format).
> :meta_glc bqbiol:is <urn:miriam:obo.chebi:CHEBI%3417234>
> :meta_glc bqbiol:is <urn:miriam:kegg.compound:C00234>
> 
> b. Figure 7 shows the annotation of a calcium-calmodulin complex, in which
> the intent is to state that the complex is composed of calcium and that the
> complex is composed of calmodulin. the mereological nature of this statement
> basically doesn't require one to state either a conjunction (which would
> imply that the value is a member of both types) or disjunction (which would
> imply that the value is a member of one or the other types), but rather
> should be treated as a set of separate statements
> 
> :cacam bqbiol:hasPart <urn:miriam:uniprot:P62158>
> :cacam bqbiol:hasPart <urn:miriam:kegg.compound:C00076>
> 
> c. Figure 8 shows how bag elements can be separated, but i question the need
> to have bag involved at any level here.
> 
> d. negative statements - the syntax for negative object assertions are
> provided by OWL2
> 
> 
> B. predicates and qualifiers
> 
> 1. "To satisfy RDF, predicates should be nouns,"
> knowledge representation languages such as RDF/OWL are agnostic when it
> comes to the choice of the characters in a symbol, safe those that are
> reserved as elements of the language. The naming of entities is entirely up
> to the modeler and has no bearing on the interpretation by a tool over the
> data. Thus, the choice of nouns or verbs are entirely within the control of
> the modeler. IMHO, verb predicates are more accurate in the nature of the
> relation, and improve the quality of tools that want to work with
> (controlled) natural language expressions. Ultimately this is a style
> choice.
> 
> 2. the list of new predicates provided in the appendix are not described,
> and hence I cannot offer my opinion on them as to their merit or whether
> they are instrinsically different relations. However, by looking at the
> names themselves, i doubt very much that this is the direction you actually
> benefit from.
> 
> C. Provenance
> 1. Statements about attributes
> While i find the use of xpath expressions to identify parts of the XML
> element that one wants to refer to as being very necessary and interesting,
> I fear that the name may not be sufficiently unique and that in a large RDF
> graph of such annotations, they would get jumbled up.
> 
> 2. Statements about statements
> The problem with the reification plan is that the assignment of internal
> identifiers (rdf:id) is never guaranteed to remain the same, and as such
> cannot be considered as linkable data. Thus annotations will necessarily
> have to be created and maintained in that same file, and this will preclude
> others from commenting on annotations. Another solution is to consider
> OWL2's annotation object, which is strongly typed to reify statements, and
> may be assigned a stable URI. Additional semantics of annotation
> 
> 3. Options: In both 1 and 2 above, i might suggest the use of miriam
> identifiers for both models and their components. I might also suggest to
> investigate the provenance ontology [
> http://trdf.sourceforge.net/provenance/ns.html]
> 
> 
> 
> 3. n-ary relations (referred to as non-binary relations)
> n-ary relations are problematic for a large number of reasons including
> restriction on the number and type of relations to the decidability of
> reasoning. For these and other reasons, OWL2 maintains only binary object
> relations (and hence the created annotations would be incompatible with an
> OWL knowledge base), which then forces one to adopt more principled/modular
> patterns in the design of expressive and reason-able ontologies. Thus, I
> would recommend to think about the nature of the entities and the relations
> that hold between them.
> 
> The use case is "Hexokinase 2 is modified by phosphoserine in position 158".
> First, the use case is badly worded, and I think it refers to either :
> 1 - there exists a variant of hexokinase 2 which contains a phosphorylated
> serine at position 158  (because surely hexokinase 2 and modified hexokinase
> 2 are two different kinds)
> 2 - there exists a process which phosphorylates hexokinase 2's serine at
> position 158 (and hence there is a regular hexokinase + phosphate as input
> and a phosphorylated hexokinase as output).
> 
> In order to express (1), we might want to state (in turtle syntax)
> :hexokinase-2-PS158
>   rdf:type :protein;
>   :is-variant-of :hexokinase-2;
>   :has-proper-part [
>        rdf:type :phosphoserine;
>       :has-attribute [
>            rdf:type :sequence-position;
>           :has-value "158"^^xsd:int]] .
> 
> in this way, we maintain the use of binary relations, and we now have new
> types which have relations that are appropriate to them.  Thus modelling can
> be better controlled, and evolution of new types with additional
> restrictions follow along the design pattern. This pattern follows what we
> are doing with the Semanticscience Integrated Ontology (SIO) -
> http://code.google.com/p/semanticscience/wiki/SIO
> 
> 
> Hope the above is helpful in refining the proposal in so that it reflects
> more powerful design patterns for the RDF/OWL Semantic Web languages.
> 
> m.
> 
> 
> -- 
> Michel Dumontier
> Associate Professor of Bioinformatics
> Carleton University
> http://dumontierlab.com
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been 
> demonstrated beyond question. Learn why your peers are replacing JEE 
> containers with lightweight application servers - and what you can gain 
> from the move. http://p.sf.net/sfu/vmware-sfemails
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

[sbml-annot] SBML Level 3 Package Proposal: Annotation

[Michel D. <mic...@gm...>]

Hi,
 Here are my comments regarding the SBML Level 3 Package proposal on
annotation
http://precedings.nature.com/documents/5610/version/1

A. syntax and semantics of containers and collections
Containers (bag, seq, alt) specify *groups* those in which their members may
be ordered (seq) or unordered (bag, alt), or that contain duplicates (bag,
seq) or is unique (alt).
Collections (list) specify *groups* that can only contain the specified
members.

So there are several criticisms in using this constructs for the SBML
annotations.
0 - the relation is from the species to a group which has particular
members. I don't believe this is really desireable because it both dilutes
and confuses the semantics of the relation.
1 - these constructs are seldom (if at all) used in the linked data
community. Their semantics are more amenable to being used to list items in
forms or surveys, where you actually want to order list items (e.g. HTML
ordered/unordered lists), or restrict the value choices (e.g. radio
buttons).
2 - these constructs requires one to create a different kind of SPARQL query
to get at the values. instead of asking for the value of subject, predicate
or subject-predicate expression (e.g. :a :p ?y), one now has to ask for the
member of a collection (e.g. using Jena :a :p [ rdfs:member ?y], or with no
application-specific short cut it gets significantly more ugly).
3 - these constructs are not supported in OWL (they are elements of the
syntax of the language, but not part of what modelers use)
4 - I don't think the cited examples are valid in the context of the stated
intent.
a. Figure 6 shows two annotations linked through the "is" property to a
glucose species. Given the intended semantics of "is" and that ChEBI and
KEGG are two different resources, it seems to be that what is actually meant
is that this species corresponds to (represents) the physical entities
denoted by the ChEBI and KEGG identifiers, and that these should not be
disjoint types.  I really see two distinct statements (in turtle format).
 :meta_glc bqbiol:is <urn:miriam:obo.chebi:CHEBI%3417234>
 :meta_glc bqbiol:is <urn:miriam:kegg.compound:C00234>

b. Figure 7 shows the annotation of a calcium-calmodulin complex, in which
the intent is to state that the complex is composed of calcium and that the
complex is composed of calmodulin. the mereological nature of this statement
basically doesn't require one to state either a conjunction (which would
imply that the value is a member of both types) or disjunction (which would
imply that the value is a member of one or the other types), but rather
should be treated as a set of separate statements

:cacam bqbiol:hasPart <urn:miriam:uniprot:P62158>
:cacam bqbiol:hasPart <urn:miriam:kegg.compound:C00076>

c. Figure 8 shows how bag elements can be separated, but i question the need
to have bag involved at any level here.

d. negative statements - the syntax for negative object assertions are
provided by OWL2


B. predicates and qualifiers

1. "To satisfy RDF, predicates should be nouns,"
knowledge representation languages such as RDF/OWL are agnostic when it
comes to the choice of the characters in a symbol, safe those that are
reserved as elements of the language. The naming of entities is entirely up
to the modeler and has no bearing on the interpretation by a tool over the
data. Thus, the choice of nouns or verbs are entirely within the control of
the modeler. IMHO, verb predicates are more accurate in the nature of the
relation, and improve the quality of tools that want to work with
(controlled) natural language expressions. Ultimately this is a style
choice.

2. the list of new predicates provided in the appendix are not described,
and hence I cannot offer my opinion on them as to their merit or whether
they are instrinsically different relations. However, by looking at the
names themselves, i doubt very much that this is the direction you actually
benefit from.

C. Provenance
1. Statements about attributes
While i find the use of xpath expressions to identify parts of the XML
element that one wants to refer to as being very necessary and interesting,
I fear that the name may not be sufficiently unique and that in a large RDF
graph of such annotations, they would get jumbled up.

2. Statements about statements
The problem with the reification plan is that the assignment of internal
identifiers (rdf:id) is never guaranteed to remain the same, and as such
cannot be considered as linkable data. Thus annotations will necessarily
have to be created and maintained in that same file, and this will preclude
others from commenting on annotations. Another solution is to consider
OWL2's annotation object, which is strongly typed to reify statements, and
may be assigned a stable URI. Additional semantics of annotation

3. Options: In both 1 and 2 above, i might suggest the use of miriam
identifiers for both models and their components. I might also suggest to
investigate the provenance ontology [
http://trdf.sourceforge.net/provenance/ns.html]



3. n-ary relations (referred to as non-binary relations)
n-ary relations are problematic for a large number of reasons including
restriction on the number and type of relations to the decidability of
reasoning. For these and other reasons, OWL2 maintains only binary object
relations (and hence the created annotations would be incompatible with an
OWL knowledge base), which then forces one to adopt more principled/modular
patterns in the design of expressive and reason-able ontologies. Thus, I
would recommend to think about the nature of the entities and the relations
that hold between them.

The use case is "Hexokinase 2 is modified by phosphoserine in position 158".
First, the use case is badly worded, and I think it refers to either :
1 - there exists a variant of hexokinase 2 which contains a phosphorylated
serine at position 158  (because surely hexokinase 2 and modified hexokinase
2 are two different kinds)
2 - there exists a process which phosphorylates hexokinase 2's serine at
position 158 (and hence there is a regular hexokinase + phosphate as input
and a phosphorylated hexokinase as output).

In order to express (1), we might want to state (in turtle syntax)
 :hexokinase-2-PS158
   rdf:type :protein;
   :is-variant-of :hexokinase-2;
   :has-proper-part [
        rdf:type :phosphoserine;
       :has-attribute [
            rdf:type :sequence-position;
           :has-value "158"^^xsd:int]] .

in this way, we maintain the use of binary relations, and we now have new
types which have relations that are appropriate to them.  Thus modelling can
be better controlled, and evolution of new types with additional
restrictions follow along the design pattern. This pattern follows what we
are doing with the Semanticscience Integrated Ontology (SIO) -
http://code.google.com/p/semanticscience/wiki/SIO


Hope the above is helpful in refining the proposal in so that it reflects
more powerful design patterns for the RDF/OWL Semantic Web languages.

m.


-- 
Michel Dumontier
Associate Professor of Bioinformatics
Carleton University
http://dumontierlab.com

Re: [sbml-annot] annotation spec

[Stefan H. <sh...@vb...>]

Hello All,

On 2/14/2011 4:56 PM, Nicolas Le novère wrote:
> On 14/02/11 21:33, Stefan Hoops wrote:
>
>> And he is correct with that. I even would say that any modification of
>> an SBML document is out of our hand. It is entirely possible that
>> someone changes the SBML Id or metaid or whatever unique attribute we
>> use to identify an SBML object. This will render all annotation using
>> this reference dangling as it talks about something non existing.
> I do not agree. That would be invalidating the SBML model and thus
> incorrect. It would be like changing the id of a species and making all
> formula invalid. A tool changing an id must take care of the consistency
> because the idref are part of SBML specification. Model merging is not part
> of the SBML specification.
>

I think we actually agree here too. In that we say that it is the 
modifier's (being it a tool or person) responsibility to create correct 
SBML. The problem here is that a tool unaware of the extension package 
might modify an SBML Id and correct all references within the L3 core to 
it. This would create a valid SBML L3 core model. However, the 
annotation package content will no be valid.

>> I think the only processing rule we might want stipulate is:
>> If a metaid (XMLId) is changed by a processing rule (e.g. through an
>> xml:include statement), all references to this Id within the annotation
>> package must be changed accordingly.
> Yes, we agree here.

Thanks,
Stefan




-- 
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility I
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax:   (540) 231-2606
Email: sh...@vb...

Re: [sbml-annot] annotation spec

[Nicolas Le n. <le...@eb...>]

On 14/02/11 21:33, Stefan Hoops wrote:

> And he is correct with that. I even would say that any modification of
> an SBML document is out of our hand. It is entirely possible that
> someone changes the SBML Id or metaid or whatever unique attribute we
> use to identify an SBML object. This will render all annotation using
> this reference dangling as it talks about something non existing.

I do not agree. That would be invalidating the SBML model and thus 
incorrect. It would be like changing the id of a species and making all 
formula invalid. A tool changing an id must take care of the consistency 
because the idref are part of SBML specification. Model merging is not part 
of the SBML specification.

> I think the only processing rule we might want stipulate is:
> If a metaid (XMLId) is changed by a processing rule (e.g. through an
> xml:include statement), all references to this Id within the annotation
> package must be changed accordingly.

Yes, we agree here.


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] annotation spec

[Stefan H. <sh...@vb...>]

Hello All,

On 1/24/2011 11:41 AM, Neil Swainston wrote:
> Hi Dagmar,
>
> As Nicolas said, the merging of models is out of our hands somewhat.

And he is correct with that. I even would say that any modification of 
an SBML document is out of our hand. It is entirely possible that 
someone changes the SBML Id or metaid or whatever unique attribute we 
use to identify an SBML object. This will render all annotation using 
this reference dangling as it talks about something non existing.

I think the only processing rule we might want stipulate is:
If a metaid (XMLId) is changed by a processing rule (e.g. through an 
xml:include statement), all references to this Id within the annotation 
package must be changed accordingly.

Thanks,
Stefan

-- 
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility I
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax:   (540) 231-2606
Email: sh...@vb...

Re: [sbml-annot] Proposal document...

[Nicolas Le n. <le...@eb...>]

On 31/01/11 19:40, Neil Swainston wrote:
> ...is available at the following address:
>
> http://precedings.nature.com/documents/5610/version/1

Neil, Dagmar, thank-you very much for your enthusiasm and dedication.

> Mike / Nicholas: what are the next steps? Do we have to make this known
> to the editors? I'm afraid that I'm not up-to-speed with the process.

I believe it is now implementation time. While doing so, it is likely that 
modification of the draft specification will be required. Once two software 
support the package, the document is declared public specification.

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

[sbml-annot] Proposal document...

[Neil S. <nei...@ma...>]

...is available at the following address:

http://precedings.nature.com/documents/5610/version/1

Hope all is OK, and thanks to all for your help.

Mike / Nicholas: what are the next steps? Do we have to make this known to the editors? I'm afraid that I'm not up-to-speed with the process.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

[sbml-annot] Draft proposal

[Neil S. <nei...@ma...>]

Dear All,

Thanks for all of the comments / suggestions. These have been incorporated into an updated version that is available from here:

http://dl.dropbox.com/u/8980329/Annot.doc

Given that we've been working on this since 1537, I'm intending to upload this to Nature Preceedings on Feb 1st, so please make any suggested changes / feedback before then. If I don't hear from you, I will assume that you're OK with this.

As an aside, this can obviously be updated later (I'm sure that it will be), but I'm very keen to call time on this version.

Best wishes,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

Re: [sbml-annot] annotation spec

[Neil S. <nei...@ma...>]

Hi Dagmar,

As Nicolas said, the merging of models is out of our hands somewhat. The problem that you envisage would exist anyway if annotations were present or not.

The short paths idea was simply one of convenience, I think. Rather than writing...

/sbml/model/listOfSpecies/species[id='y']

...we could get away with...

//species[id='y']

...as, in the case of SBML as it is currently, *all* species are found under /sbml/model/listOfSpecies. So there would be no ambiguity.

The point of the ancestor-or-self::species[1]/@initialConcentration syntax was to ensure that the annotation belongs to parent node. Consider the following, hypothetical SBML:

<species id="a">
	<species id="b">
		<species id="c">
			<annotation... about="ancestor-or-self::species[1]/@initialConcentration">

ancestor-or-self::species would return a set of nodes, representing ids c, b and a (in that order). Specifying species[1] is simply saying "give me the first instance of a parent node who element name is species" (in this case, with id="c"). (species[2] refers to b, and species[3] refers to a).

However, this is all redundant, given that Nicolas correctly points out that none of these hypothetical merging problems have to be dealt with by us.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 22 Jan 2011, at 19:12, Dagmar Waltemath wrote:

> Hi,
> 
> 
> On 01/21/2011 04:44 PM, Neil Swainston wrote:
>> Hi Nick,
>> 
>> You make a good point here regarding annotation of attributes.
>> 
>> Everyone else: if we are merging two files, is the use of XPath as we now suggest OK?
>> 
>> For example...
>> 
>> //species[id='y']/@initialConcentration
>> 
>> If a species id="y" is in both files, how do we know which one we're refering to?
> 
> Am I right assuming that we have  a problem anyways if merging two SBML 
> files with identical species names, e.g. which species[id='y'] are we 
> referring to from a reaction in the speciesference? Is that valid 
> SBML/XML actually?
> 
> But, again, I wasn't sure why we said to prefer the short paths to the 
> complete ones? Can anyone help me?
> 
>> Another way would be to use...
>> 
>> ancestor-or-self::species[1]/@initialConcentration
>> 
>> Which, when used in an annotation tag, would find the first parent "species" element above the annotation. i.e. the annotation would refer to the species in which it is enclosed.
> 
> Did we not exclude this because species orders might get mixed up, e.g. 
> when loading SBML files in and out of software tools? (SBML doesn't 
> force any order on its elements?)
> 
> Dagmar
> 
> 
> 
>> This may be a non-issue. But if anyone responds I'd be happy to discuss further.
>> 
>> Cheers,
>> 
>> Neil.
>> 
>> Neil Swainston
>> Experimental Officer
>> 
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>> 
>> On 21 Jan 2011, at 15:29, Nick Juty wrote:
>> 
>>> Cheers for getting back to me ;p
>>> 
>>> For the XPath thing, I was thinking if you merged 2 models, each with an element with id=y (say), the new model would have 2 different y ids, would that cause issues? Not being familiar with validation of SBML, at what point does the new model become invalid? eg I imagined someone hacking together 2 submodels without computational assistance (just to be complicated)....
>>> 
>>> For the anno: prefix, you're right - it could be giraffe - which strangely sounds good!
>>> 
>>> cheers!
>>> 
>>> Nick
>>> 
>>> Neil Swainston wrote:
>>>> Cheers, Nick,
>>>> I've merged in your changes with some that Dagmar suggested:
>>>> http://dl.dropbox.com/u/8980329/Annot.doc
>>>> Hope the link now works.
>>>> Regarding using ids in XPath statements, SBML requires that ids are unique within a model. So the situation that you mention shoudn't arise, I guess? (Or are you considering some modular extension of Level 3 that I'm not fully familiar with?)
>>>> With the annot:annotation thing, I guess it is a little confusing, but these should only ever be read by software anyways. The annot prefix is only really shorthand for the full namespace...
>>>> http://www.sbml.org/sbml/level3/version1/annot/version1
>>>> ..so in principle one could change this to "giraffe" of whatever and the RDF would still be valid. Do you have any suggestions, though? It's certainly not too late to raise any issues.
>>>> Cheers,
>>>> Neil.
>>>> Neil Swainston
>>>> Experimental Officer
>>>> Manchester Centre for Integrative Systems Biology
>>>> Manchester Interdisciplinary Biocentre
>>>> University of Manchester
>>>> Manchester M1 7DN
>>>> United Kingdom
>>>> On 21 Jan 2011, at 14:07, Nick Juty wrote:
>>>>> Hi Neil,
>>>>> 
>>>>> Just going through the proposal.
>>>>> I have a couple of questions/comments. Pretty much all of this is optional though - feel free to ignore as much of it as you wish. In fact you could conceivably just trash the email completely ;p
>>>>> 
>>>>> Have a good weekend!
>>>>> 
>>>>> cheers
>>>>> 
>>>>> Nick
>>>>> 
>>>>> Ps Well actually the 1st point I would change for accuracy ...
>>>>> 
>>>>> =========================
>>>>> Page 5 - "To uniquely identify a controlled vocabulary term or object, the MIRIAM Resources scheme is used."
>>>>> I would change that to the scheme described in the MIRIAM Standard.
>>>>> 
>>>>> Page 6 - "FURTHER RDF:LI ELEMENT"
>>>>> Would it be possible to expand the example to actually show 2 URIs (say Ex1, Ex2), then modify the sentence below to something like:
>>>>> ...RDF provides three additional concepts to encode the relations between the statements, Ex1 and Ex2 above, other than the one (rdf:bag) to which the core spec is currently limited.
>>>>> The examples below do detail it well though - so thats optional!
>>>>> 
>>>>> Page 7 - "Furthermore, no clear definition of the different or similar meanings between the following two examples is provided:"
>>>>> Furthermore, there is no clear definition that states the semantic difference between the 2 alternative encodings of the same information below:
>>>>> 
>>>>> Page 9 - "Adding the XML attribute annot:required to the<sbml>  element and setting its value to false indicates this:"
>>>>> would reword that to something like: This can be defined by adding the XML attribute annot:required to the<sbml>  element, and setting its value to false:
>>>>> 
>>>>> Page 9 - XPath question. //x['y'] selects the x nodes, with id=y. What happens when you have 2 models stitched together and there is more than 1 'y'?
>>>>> 
>>>>> Page 12 comment - annot:annotation looks messy to me. If I was not familiar with the spec/core/extenstions, and used SBML for the first time, I would think my parser/writer had stuttered or something. I guess its too late to propose something else?
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
> 
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] annotation spec

[Neil S. <nei...@ma...>]

Hi Dagmar,

As Nicolas said, the merging of models is out of our hands somewhat. The problem that you envisage would exist anyway if annotations were present or not.

The short paths idea was simply one of convenience, I think. Rather than writing...

/sbml/model/listOfSpecies/species[id='y']

...we could get away with...

//species[id='y']

...as, in the case of SBML as it is currently, *all* species are found under /sbml/model/listOfSpecies. So there would be no ambiguity.

The point of the ancestor-or-self::species[1]/@initialConcentration syntax was to ensure that the annotation belongs to parent node. Consider the following, hypothetical SBML:

<species id="a">
	<species id="b">
		<species id="c">
			<annotation... about="ancestor-or-self::species[1]/@initialConcentration">

ancestor-or-self::species would return a set of nodes, representing ids c, b and a (in that order). Specifying species[1] is simply saying "give me the first instance of a parent node who element name is species" (in this case, with id="c"). (species[2] refers to b, and species[3] refers to a).

However, this is all redundant, given that Nicolas correctly points out that none of these hypothetical merging problems have to be dealt with by us.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 22 Jan 2011, at 19:12, Dagmar Waltemath wrote:

> Hi,
> 
> 
> On 01/21/2011 04:44 PM, Neil Swainston wrote:
>> Hi Nick,
>> 
>> You make a good point here regarding annotation of attributes.
>> 
>> Everyone else: if we are merging two files, is the use of XPath as we now suggest OK?
>> 
>> For example...
>> 
>> //species[id='y']/@initialConcentration
>> 
>> If a species id="y" is in both files, how do we know which one we're refering to?
> 
> Am I right assuming that we have  a problem anyways if merging two SBML 
> files with identical species names, e.g. which species[id='y'] are we 
> referring to from a reaction in the speciesference? Is that valid 
> SBML/XML actually?
> 
> But, again, I wasn't sure why we said to prefer the short paths to the 
> complete ones? Can anyone help me?
> 
>> Another way would be to use...
>> 
>> ancestor-or-self::species[1]/@initialConcentration
>> 
>> Which, when used in an annotation tag, would find the first parent "species" element above the annotation. i.e. the annotation would refer to the species in which it is enclosed.
> 
> Did we not exclude this because species orders might get mixed up, e.g. 
> when loading SBML files in and out of software tools? (SBML doesn't 
> force any order on its elements?)
> 
> Dagmar
> 
> 
> 
>> This may be a non-issue. But if anyone responds I'd be happy to discuss further.
>> 
>> Cheers,
>> 
>> Neil.
>> 
>> Neil Swainston
>> Experimental Officer
>> 
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>> 
>> On 21 Jan 2011, at 15:29, Nick Juty wrote:
>> 
>>> Cheers for getting back to me ;p
>>> 
>>> For the XPath thing, I was thinking if you merged 2 models, each with an element with id=y (say), the new model would have 2 different y ids, would that cause issues? Not being familiar with validation of SBML, at what point does the new model become invalid? eg I imagined someone hacking together 2 submodels without computational assistance (just to be complicated)....
>>> 
>>> For the anno: prefix, you're right - it could be giraffe - which strangely sounds good!
>>> 
>>> cheers!
>>> 
>>> Nick
>>> 
>>> Neil Swainston wrote:
>>>> Cheers, Nick,
>>>> I've merged in your changes with some that Dagmar suggested:
>>>> http://dl.dropbox.com/u/8980329/Annot.doc
>>>> Hope the link now works.
>>>> Regarding using ids in XPath statements, SBML requires that ids are unique within a model. So the situation that you mention shoudn't arise, I guess? (Or are you considering some modular extension of Level 3 that I'm not fully familiar with?)
>>>> With the annot:annotation thing, I guess it is a little confusing, but these should only ever be read by software anyways. The annot prefix is only really shorthand for the full namespace...
>>>> http://www.sbml.org/sbml/level3/version1/annot/version1
>>>> ..so in principle one could change this to "giraffe" of whatever and the RDF would still be valid. Do you have any suggestions, though? It's certainly not too late to raise any issues.
>>>> Cheers,
>>>> Neil.
>>>> Neil Swainston
>>>> Experimental Officer
>>>> Manchester Centre for Integrative Systems Biology
>>>> Manchester Interdisciplinary Biocentre
>>>> University of Manchester
>>>> Manchester M1 7DN
>>>> United Kingdom
>>>> On 21 Jan 2011, at 14:07, Nick Juty wrote:
>>>>> Hi Neil,
>>>>> 
>>>>> Just going through the proposal.
>>>>> I have a couple of questions/comments. Pretty much all of this is optional though - feel free to ignore as much of it as you wish. In fact you could conceivably just trash the email completely ;p
>>>>> 
>>>>> Have a good weekend!
>>>>> 
>>>>> cheers
>>>>> 
>>>>> Nick
>>>>> 
>>>>> Ps Well actually the 1st point I would change for accuracy ...
>>>>> 
>>>>> =========================
>>>>> Page 5 - "To uniquely identify a controlled vocabulary term or object, the MIRIAM Resources scheme is used."
>>>>> I would change that to the scheme described in the MIRIAM Standard.
>>>>> 
>>>>> Page 6 - "FURTHER RDF:LI ELEMENT"
>>>>> Would it be possible to expand the example to actually show 2 URIs (say Ex1, Ex2), then modify the sentence below to something like:
>>>>> ...RDF provides three additional concepts to encode the relations between the statements, Ex1 and Ex2 above, other than the one (rdf:bag) to which the core spec is currently limited.
>>>>> The examples below do detail it well though - so thats optional!
>>>>> 
>>>>> Page 7 - "Furthermore, no clear definition of the different or similar meanings between the following two examples is provided:"
>>>>> Furthermore, there is no clear definition that states the semantic difference between the 2 alternative encodings of the same information below:
>>>>> 
>>>>> Page 9 - "Adding the XML attribute annot:required to the<sbml>  element and setting its value to false indicates this:"
>>>>> would reword that to something like: This can be defined by adding the XML attribute annot:required to the<sbml>  element, and setting its value to false:
>>>>> 
>>>>> Page 9 - XPath question. //x['y'] selects the x nodes, with id=y. What happens when you have 2 models stitched together and there is more than 1 'y'?
>>>>> 
>>>>> Page 12 comment - annot:annotation looks messy to me. If I was not familiar with the spec/core/extenstions, and used SBML for the first time, I would think my parser/writer had stuttered or something. I guess its too late to propose something else?
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
> 
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] annotation spec

[Nicolas Le n. <le...@eb...>]

My 2-cents: Merging of SBML files is none of SBML business. There is a 
package on model composition. We have to cope with this situation, not the 
merging. Annotations are contained in their elements. With model 
composition, there is no ambiguity.

But this is a good reason why model composition should always be done using 
complete SBML elements, and not random pieces of XML as it has been suggested.

On 22/01/11 19:12, Dagmar Waltemath wrote:
> Hi,
>
>
> On 01/21/2011 04:44 PM, Neil Swainston wrote:
>> Hi Nick,
>>
>> You make a good point here regarding annotation of attributes.
>>
>> Everyone else: if we are merging two files, is the use of XPath as we now suggest OK?
>>
>> For example...
>>
>> //species[id='y']/@initialConcentration
>>
>> If a species id="y" is in both files, how do we know which one we're refering to?
>
> Am I right assuming that we have  a problem anyways if merging two SBML
> files with identical species names, e.g. which species[id='y'] are we
> referring to from a reaction in the speciesference? Is that valid
> SBML/XML actually?
>
> But, again, I wasn't sure why we said to prefer the short paths to the
> complete ones? Can anyone help me?
>
>> Another way would be to use...
>>
>> ancestor-or-self::species[1]/@initialConcentration
>>
>> Which, when used in an annotation tag, would find the first parent "species" element above the annotation. i.e. the annotation would refer to the species in which it is enclosed.
>
> Did we not exclude this because species orders might get mixed up, e.g.
> when loading SBML files in and out of software tools? (SBML doesn't
> force any order on its elements?)
>
> Dagmar
>
>
>
>> This may be a non-issue. But if anyone responds I'd be happy to discuss further.
>>
>> Cheers,
>>
>> Neil.
>>
>> Neil Swainston
>> Experimental Officer
>>
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>>
>> On 21 Jan 2011, at 15:29, Nick Juty wrote:
>>
>>> Cheers for getting back to me ;p
>>>
>>> For the XPath thing, I was thinking if you merged 2 models, each with an element with id=y (say), the new model would have 2 different y ids, would that cause issues? Not being familiar with validation of SBML, at what point does the new model become invalid? eg I imagined someone hacking together 2 submodels without computational assistance (just to be complicated)....
>>>
>>> For the anno: prefix, you're right - it could be giraffe - which strangely sounds good!
>>>
>>> cheers!
>>>
>>> Nick
>>>
>>> Neil Swainston wrote:
>>>> Cheers, Nick,
>>>> I've merged in your changes with some that Dagmar suggested:
>>>> http://dl.dropbox.com/u/8980329/Annot.doc
>>>> Hope the link now works.
>>>> Regarding using ids in XPath statements, SBML requires that ids are unique within a model. So the situation that you mention shoudn't arise, I guess? (Or are you considering some modular extension of Level 3 that I'm not fully familiar with?)
>>>> With the annot:annotation thing, I guess it is a little confusing, but these should only ever be read by software anyways. The annot prefix is only really shorthand for the full namespace...
>>>> http://www.sbml.org/sbml/level3/version1/annot/version1
>>>> ..so in principle one could change this to "giraffe" of whatever and the RDF would still be valid. Do you have any suggestions, though? It's certainly not too late to raise any issues.
>>>> Cheers,
>>>> Neil.
>>>> Neil Swainston
>>>> Experimental Officer
>>>> Manchester Centre for Integrative Systems Biology
>>>> Manchester Interdisciplinary Biocentre
>>>> University of Manchester
>>>> Manchester M1 7DN
>>>> United Kingdom
>>>> On 21 Jan 2011, at 14:07, Nick Juty wrote:
>>>>> Hi Neil,
>>>>>
>>>>> Just going through the proposal.
>>>>> I have a couple of questions/comments. Pretty much all of this is optional though - feel free to ignore as much of it as you wish. In fact you could conceivably just trash the email completely ;p
>>>>>
>>>>> Have a good weekend!
>>>>>
>>>>> cheers
>>>>>
>>>>> Nick
>>>>>
>>>>> Ps Well actually the 1st point I would change for accuracy ...
>>>>>
>>>>> =========================
>>>>> Page 5 - "To uniquely identify a controlled vocabulary term or object, the MIRIAM Resources scheme is used."
>>>>> I would change that to the scheme described in the MIRIAM Standard.
>>>>>
>>>>> Page 6 - "FURTHER RDF:LI ELEMENT"
>>>>> Would it be possible to expand the example to actually show 2 URIs (say Ex1, Ex2), then modify the sentence below to something like:
>>>>> ...RDF provides three additional concepts to encode the relations between the statements, Ex1 and Ex2 above, other than the one (rdf:bag) to which the core spec is currently limited.
>>>>> The examples below do detail it well though - so thats optional!
>>>>>
>>>>> Page 7 - "Furthermore, no clear definition of the different or similar meanings between the following two examples is provided:"
>>>>> Furthermore, there is no clear definition that states the semantic difference between the 2 alternative encodings of the same information below:
>>>>>
>>>>> Page 9 - "Adding the XML attribute annot:required to the<sbml>   element and setting its value to false indicates this:"
>>>>> would reword that to something like: This can be defined by adding the XML attribute annot:required to the<sbml>   element, and setting its value to false:
>>>>>
>>>>> Page 9 - XPath question. //x['y'] selects the x nodes, with id=y. What happens when you have 2 models stitched together and there is more than 1 'y'?
>>>>>
>>>>> Page 12 comment - annot:annotation looks messy to me. If I was not familiar with the spec/core/extenstions, and used SBML for the first time, I would think my parser/writer had stuttered or something. I guess its too late to propose something else?
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] annotation spec

[Dagmar W. <dag...@un...>]

Hi,


On 01/21/2011 04:44 PM, Neil Swainston wrote:
> Hi Nick,
>
> You make a good point here regarding annotation of attributes.
>
> Everyone else: if we are merging two files, is the use of XPath as we now suggest OK?
>
> For example...
>
> //species[id='y']/@initialConcentration
>
> If a species id="y" is in both files, how do we know which one we're refering to?

Am I right assuming that we have  a problem anyways if merging two SBML 
files with identical species names, e.g. which species[id='y'] are we 
referring to from a reaction in the speciesference? Is that valid 
SBML/XML actually?

But, again, I wasn't sure why we said to prefer the short paths to the 
complete ones? Can anyone help me?

> Another way would be to use...
>
> ancestor-or-self::species[1]/@initialConcentration
>
> Which, when used in an annotation tag, would find the first parent "species" element above the annotation. i.e. the annotation would refer to the species in which it is enclosed.

Did we not exclude this because species orders might get mixed up, e.g. 
when loading SBML files in and out of software tools? (SBML doesn't 
force any order on its elements?)

Dagmar



> This may be a non-issue. But if anyone responds I'd be happy to discuss further.
>
> Cheers,
>
> Neil.
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
>
> On 21 Jan 2011, at 15:29, Nick Juty wrote:
>
>> Cheers for getting back to me ;p
>>
>> For the XPath thing, I was thinking if you merged 2 models, each with an element with id=y (say), the new model would have 2 different y ids, would that cause issues? Not being familiar with validation of SBML, at what point does the new model become invalid? eg I imagined someone hacking together 2 submodels without computational assistance (just to be complicated)....
>>
>> For the anno: prefix, you're right - it could be giraffe - which strangely sounds good!
>>
>> cheers!
>>
>> Nick
>>
>> Neil Swainston wrote:
>>> Cheers, Nick,
>>> I've merged in your changes with some that Dagmar suggested:
>>> http://dl.dropbox.com/u/8980329/Annot.doc
>>> Hope the link now works.
>>> Regarding using ids in XPath statements, SBML requires that ids are unique within a model. So the situation that you mention shoudn't arise, I guess? (Or are you considering some modular extension of Level 3 that I'm not fully familiar with?)
>>> With the annot:annotation thing, I guess it is a little confusing, but these should only ever be read by software anyways. The annot prefix is only really shorthand for the full namespace...
>>> http://www.sbml.org/sbml/level3/version1/annot/version1
>>> ..so in principle one could change this to "giraffe" of whatever and the RDF would still be valid. Do you have any suggestions, though? It's certainly not too late to raise any issues.
>>> Cheers,
>>> Neil.
>>> Neil Swainston
>>> Experimental Officer
>>> Manchester Centre for Integrative Systems Biology
>>> Manchester Interdisciplinary Biocentre
>>> University of Manchester
>>> Manchester M1 7DN
>>> United Kingdom
>>> On 21 Jan 2011, at 14:07, Nick Juty wrote:
>>>> Hi Neil,
>>>>
>>>> Just going through the proposal.
>>>> I have a couple of questions/comments. Pretty much all of this is optional though - feel free to ignore as much of it as you wish. In fact you could conceivably just trash the email completely ;p
>>>>
>>>> Have a good weekend!
>>>>
>>>> cheers
>>>>
>>>> Nick
>>>>
>>>> Ps Well actually the 1st point I would change for accuracy ...
>>>>
>>>> =========================
>>>> Page 5 - "To uniquely identify a controlled vocabulary term or object, the MIRIAM Resources scheme is used."
>>>> I would change that to the scheme described in the MIRIAM Standard.
>>>>
>>>> Page 6 - "FURTHER RDF:LI ELEMENT"
>>>> Would it be possible to expand the example to actually show 2 URIs (say Ex1, Ex2), then modify the sentence below to something like:
>>>> ...RDF provides three additional concepts to encode the relations between the statements, Ex1 and Ex2 above, other than the one (rdf:bag) to which the core spec is currently limited.
>>>> The examples below do detail it well though - so thats optional!
>>>>
>>>> Page 7 - "Furthermore, no clear definition of the different or similar meanings between the following two examples is provided:"
>>>> Furthermore, there is no clear definition that states the semantic difference between the 2 alternative encodings of the same information below:
>>>>
>>>> Page 9 - "Adding the XML attribute annot:required to the<sbml>  element and setting its value to false indicates this:"
>>>> would reword that to something like: This can be defined by adding the XML attribute annot:required to the<sbml>  element, and setting its value to false:
>>>>
>>>> Page 9 - XPath question. //x['y'] selects the x nodes, with id=y. What happens when you have 2 models stitched together and there is more than 1 'y'?
>>>>
>>>> Page 12 comment - annot:annotation looks messy to me. If I was not familiar with the spec/core/extenstions, and used SBML for the first time, I would think my parser/writer had stuttered or something. I guess its too late to propose something else?
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] annotation spec

[Neil S. <nei...@ma...>]

Hi Nick,

You make a good point here regarding annotation of attributes.

Everyone else: if we are merging two files, is the use of XPath as we now suggest OK?

For example...

//species[id='y']/@initialConcentration

If a species id="y" is in both files, how do we know which one we're refering to?

Another way would be to use...

ancestor-or-self::species[1]/@initialConcentration

Which, when used in an annotation tag, would find the first parent "species" element above the annotation. i.e. the annotation would refer to the species in which it is enclosed.

This may be a non-issue. But if anyone responds I'd be happy to discuss further.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 21 Jan 2011, at 15:29, Nick Juty wrote:

> Cheers for getting back to me ;p
> 
> For the XPath thing, I was thinking if you merged 2 models, each with an element with id=y (say), the new model would have 2 different y ids, would that cause issues? Not being familiar with validation of SBML, at what point does the new model become invalid? eg I imagined someone hacking together 2 submodels without computational assistance (just to be complicated)....
> 
> For the anno: prefix, you're right - it could be giraffe - which strangely sounds good!
> 
> cheers!
> 
> Nick
> 
> Neil Swainston wrote:
>> Cheers, Nick,
>> I've merged in your changes with some that Dagmar suggested:
>> http://dl.dropbox.com/u/8980329/Annot.doc
>> Hope the link now works.
>> Regarding using ids in XPath statements, SBML requires that ids are unique within a model. So the situation that you mention shoudn't arise, I guess? (Or are you considering some modular extension of Level 3 that I'm not fully familiar with?)
>> With the annot:annotation thing, I guess it is a little confusing, but these should only ever be read by software anyways. The annot prefix is only really shorthand for the full namespace...
>> http://www.sbml.org/sbml/level3/version1/annot/version1
>> ..so in principle one could change this to "giraffe" of whatever and the RDF would still be valid. Do you have any suggestions, though? It's certainly not too late to raise any issues.
>> Cheers,
>> Neil.
>> Neil Swainston
>> Experimental Officer
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>> On 21 Jan 2011, at 14:07, Nick Juty wrote:
>>> Hi Neil,
>>> 
>>> Just going through the proposal.
>>> I have a couple of questions/comments. Pretty much all of this is optional though - feel free to ignore as much of it as you wish. In fact you could conceivably just trash the email completely ;p
>>> 
>>> Have a good weekend!
>>> 
>>> cheers
>>> 
>>> Nick
>>> 
>>> Ps Well actually the 1st point I would change for accuracy ...
>>> 
>>> =========================
>>> Page 5 - "To uniquely identify a controlled vocabulary term or object, the MIRIAM Resources scheme is used."
>>> I would change that to the scheme described in the MIRIAM Standard.
>>> 
>>> Page 6 - "FURTHER RDF:LI ELEMENT"
>>> Would it be possible to expand the example to actually show 2 URIs (say Ex1, Ex2), then modify the sentence below to something like:
>>> ...RDF provides three additional concepts to encode the relations between the statements, Ex1 and Ex2 above, other than the one (rdf:bag) to which the core spec is currently limited.
>>> The examples below do detail it well though - so thats optional!
>>> 
>>> Page 7 - "Furthermore, no clear definition of the different or similar meanings between the following two examples is provided:"
>>> Furthermore, there is no clear definition that states the semantic difference between the 2 alternative encodings of the same information below:
>>> 
>>> Page 9 - "Adding the XML attribute annot:required to the <sbml> element and setting its value to false indicates this:"
>>> would reword that to something like: This can be defined by adding the XML attribute annot:required to the <sbml> element, and setting its value to false:
>>> 
>>> Page 9 - XPath question. //x['y'] selects the x nodes, with id=y. What happens when you have 2 models stitched together and there is more than 1 'y'?
>>> 
>>> Page 12 comment - annot:annotation looks messy to me. If I was not familiar with the spec/core/extenstions, and used SBML for the first time, I would think my parser/writer had stuttered or something. I guess its too late to propose something else?

Re: [sbml-annot] [Biomodels-net-discuss] SBML Level 3 Annotation package proposal

[Mike H. <mh...@ca...>]

I don't have strong opinions on this, so you guys decide :-)

MH

Re: [sbml-annot] [Biomodels-net-discuss] SBML Level 3 Annotation package proposal

[Nick J. <ju...@eb...>]

Hi,

Couple of things...
First, since we have some new options being suggested, and I am tracking preferences, I thought I better post all the 'new' options for consideration. 
You can view the current list here:
http://www.ebi.ac.uk/~juty/misc/qualifier_preferences.pdf

Other stuff inline below..

cheers

Nick

Dagmar Waltemath wrote:
> Hello,
> 
> On 01/19/2011 06:16 AM, Mike Hucka wrote:
>> FWIW, my $0.02:
>>
>>> 1) bqmodel:isDerivedFrom
>>>
>>> bqmodel:progenitor, bqmodel:antecedent, bqmodel:ancestor, bqmodel:basis,
>>> bqmodel:base, bqmodel:foundation, bqmodel:origin
>>>
>>> Neil favours "antecedent". I favour "origin".
>> I think origin is less desirable because IMHO it has a sense of an ultimate starting point, rather than "the thing right before".  So I would also favor antecedent or ancestor here.
> 
> I prefer ancestor to antecedent (a word I have never heard before, to be 
> honest...)
> I also like the idea of "base" somehow as both "origin" and 
> "ancestor"/"antecedent" imply a notion of time in my understanding of 
> the words?...
> And I was wondering: if "isDerivedFrom" was a good qualifier, why don't 
> we just go for "derivative"?
That becomes the inverse sense. ie. If X is derived from Y, then Y has derivative whose value is X.
> 
>>> 2) bqbiol:isPartOf
>>> bqbiol:encompassment, bqbiol:assembly, bqbiol:partship, bqbiol:parthood,
>>> bqbiol:whole, bqbiol:meronym
>>>
>>> Neil favours "parthood". I favour "whole".
>> This may be a stupid question, but is it always the case that the thing being referred to is in fact the "whole", as opposed to another subpart within a larger context?  I think it's the latter, and so I think "whole" isn't always going to be the appropriate sense.  I also dislike "parthood".
>>
>> Would "constituent" be an option here?
> 
> I like "constituent", but would propose it as an alternative to "hasPart".
> Part/whole would be ok for me.
> I also thought about "belonging" which sounds pretty good (X has 
> BELONGING Y??).

I think 'part' is still the preferable equivalent noun for 'hasPart'. Do we need to reopen that one?

> 
> Dagmar
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Dagmar W. <dag...@un...>]

On 01/19/2011 01:34 PM, Stefan Hoops wrote:
> Hello Dagmar,
>
> I completely agree with you. At least the discussion needs to be
> removed. The problem is how shall we construct the examples especially
> in the view of the proposed changes. I would like the new NOUN versions
> to be used.

Hej Stefan,

we should definitely use the noun version in the proposal...
so either we use examples with the already "fixed" noun-ish qualifiers 
(e.g. identity),
or we wait and adjust the examples again as soon as biomodels.net 
updated their list :-)

I'd try and go for option 1.

Dagmar


> Thanks,
> Stefan
>
>
> On 1/17/11 4:47 PM, Dagmar Waltemath wrote:
>> Hello everyone,
>>
>>
>> it seems I am the only one complaining about it, but I have to mention it again (sorry ;-)).
>> I really find it a mistake to put the qualifiers into the Anot specification...
>>
>> The reason being that the spec it is an SBML package proposal.
>> Therefore, the new qualifiers would be "limited" to SBML people... but they are a biomodels.net concept - and there we always claim not to be tight to SBML.
>>
>> So, please, could we just refer to qualifiers out of the annot package, like link to the biomodels.net/qualifiers web site
>> and leave the rest to the biomodels.net people (who are not too different from this list)?
>>
>> That will allow others, like CellML people, to use the new qualifiers as well.
>>
>>
>> ...please, if you disagree with me, share you counter arguments with me :-)
>> Dagmar
>>
>> ________________________________________
>> From: Neil Swainston [nei...@ma...]
>> Sent: 17 January 2011 19:32
>> To: Neil Swainston
>> Cc: sbm...@li...
>> Subject: Re: [sbml-annot] SBML Level 3 Annotation package proposal
>>
>> Hi all,
>>
>> Looks like listserv has eaten the document.
>>
>> Try the following:
>>
>> ftp://ftp.dbkgroup.org/pub/annot/SBML Level 3 Package Proposal - Annot.doc
>>
>> Cheers,
>>
>> Neil.
>>
>> Neil Swainston
>> Experimental Officer
>>
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>>
>> On 17 Jan 2011, at 18:27, Neil Swainston wrote:
>>
>>> Dear all,
>>>
>>> Final one from me today...
>>>
>>> Enclosed is the draft of the SBML Level 3 Annotation package proposal.
>>>
>>> We've come a long way since the initial meeting, so thanks very much to everyone for their contributions.
>>>
>>> I'd be very grateful if you could look through the enclosed document, which is essentially the cleaned-up wiki page that we've been editing on the SBML site. Please feel free to add comments, make changes, but please use "Track Changes" on Word so that we can follow the updates.
>>>
>>> You'll note that Nick Juty's suggestions for new predicates has been added as a table towards the end of the document. Where there are multiple candidates, I've highlighted my personal preference in bold, but obviously this is all open for discussion. Please let me know your preference (if you have one).
>>>
>>> My intention is to get this finished off and get this submitted to Nature Precedings so that we have a first, fixed version that can be looked over by the SBML Editors. I'd be therefore very grateful if you could make any changes or comments by Friday 28th January.
>>>
>>> Best wishes,
>>>
>>> Neil.
>>>
>>>
>>>
>>> Neil Swainston
>>> Experimental Officer
>>>
>>> Manchester Centre for Integrative Systems Biology
>>> Manchester Interdisciplinary Biocentre
>>> University of Manchester
>>> Manchester M1 7DN
>>> United Kingdom
>>>
>>> On 13 Jan 2011, at 13:52, Nicolas Le novère wrote:
>>>
>>>> On 13/01/11 13:41, Ron Henkel wrote:
>>>>> Hi,
>>>>>
>>>>> How strict is the requirement that a qualifier needs to be a noun (or
>>>>> better exactly one noun)?
>>>>>
>>>>> For example the 'isEncodedBy' qualifier: if we used "encoder" here it
>>>>> might be confused, for example, with the person who is the encoder.
>>>>>
>>>>> So I was thinking if it is possible to use something as "encodingDNA".
>>>>> It might ease the finding of proper qualifier terms. Would this still be
>>>>> a valid predicate since it is not exactly a noun?
>>>> I think this kind of thing would in principle be fine even if not elegant.
>>>> Note that in that case, it would not work because this is not restricted to
>>>> DNA. In general I would ban all biological meaning from the qualifiers.
>>>>
>>>> But I believe you found another candidate: encoding
>>>>
>>>>> Cheers,
>>>>> Ron
>>>>>
>>>>> On 13.01.2011 14:23, Nick Juty wrote:
>>>>>> Dear annotation package people,
>>>>>>
>>>>>> I thought it would be worth opening up the discussion about BioModels.net qualifiers, in order to start moving forward more earnestly.
>>>>>> The premise is that we wish to have qualifiers that follow the "SUBJECT has PREDICATE whose value is OBJECT" statement, and thereby need to convert or
>>>>>> add additional qualifiers as nouns, rather than the existing situation where they are verbs.
>>>>>>
>>>>>> Below is a list of potential candidate equivalents to existing qualifiers found here: http://biomodels.net/qualifiers/
>>>>>>
>>>>>> In some cases, the noun translation is quite apparent, and in others, not so much ;p I think if we iterate round a little, we can reach a moderate
>>>>>> consensus.
>>>>>>
>>>>>>
>>>>>> model-qualifiers
>>>>>> ================
>>>>>> is =>     'identity'
>>>>>> isDescribedBy =>     'description'
>>>>>>
>>>>>>
>>>>>> biology-qualifier
>>>>>> ================
>>>>>> hasPart =>     'part'
>>>>>> hasProperty =>     'property'
>>>>>> hasVersion =>     'version', (relates class to instance; animal is a hypernym of cat)
>>>>>> is =>     'identity'
>>>>>> isDescribedBy =>     'description'
>>>>>> isHomologTo =>     'homolog(ue)'
>>>>>>
>>>>>>
>>>>>> The next few are more difficult, and I have collected together candidate 'equivalents'.
>>>>>>
>>>>>> model-qualifiers:
>>>>>> ================
>>>>>> 'isDerivedFrom' - needs to reflect modifications to an original model.
>>>>>> Candidates: progenitor, antecedent, ancestor, basis, base, foundation, origin
>>>>>>
>>>>>> biology-qualifiers:
>>>>>> ================
>>>>>> 'isEncodedBy' - e.g. protein is encoded by DNA
>>>>>> Candidates: encoder
>>>>>>
>>>>>> 'encodes' - e.g. DNA encodes protein
>>>>>> Candidates: encodement
>>>>>>
>>>>>> 'isPartOf' - e.g. subunit A is part of complex B
>>>>>> Candidates: encompassment, assembly, partship, parthood, whole, meronym (relates part to whole; finger is a meronym of hand)
>>>>>>
>>>>>> 'isPropertyOf' - e.g. enzyme activity A is property of entity B
>>>>>> Candidates: bearer, carrier,
>>>>>>
>>>>>> 'isVersionOf' - needs to convey the sense of belonging to some class
>>>>>> Candidates: consociate, cohort, superclass, hyponym (relates instance to class to; cat is a hyponym of animal)
>>>>>>
>>>>>> 'occursIn' - may be sensible to split it into 'physical containment' and 'taxonomic instantiation' types.
>>>>>> We could use 'encompassment' or 'containment' ('container'), for the physical type, and 'instantiation' for occurrence in a species.
>>>>>>
>>>>>> I'd appreciate your thoughts on these, and also on other qualifiers you guys have in mind.
>>>>>>
>>>>>> cheers,
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>> can protect your company and customers by using code signing.
>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>> _______________________________________________
>>>>>> Sbml-annot mailing list
>>>>>> Sbm...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>
>>>> --
>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Sbml-annot mailing list
>>>> Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>

Re: [sbml-annot] [Biomodels-net-discuss] SBML Level 3 Annotation package proposal

[Dagmar W. <dag...@un...>]

Hello,

On 01/19/2011 06:16 AM, Mike Hucka wrote:
> FWIW, my $0.02:
>
>> 1) bqmodel:isDerivedFrom
>>
>> bqmodel:progenitor, bqmodel:antecedent, bqmodel:ancestor, bqmodel:basis,
>> bqmodel:base, bqmodel:foundation, bqmodel:origin
>>
>> Neil favours "antecedent". I favour "origin".
> I think origin is less desirable because IMHO it has a sense of an ultimate starting point, rather than "the thing right before".  So I would also favor antecedent or ancestor here.

I prefer ancestor to antecedent (a word I have never heard before, to be 
honest...)
I also like the idea of "base" somehow as both "origin" and 
"ancestor"/"antecedent" imply a notion of time in my understanding of 
the words?...
And I was wondering: if "isDerivedFrom" was a good qualifier, why don't 
we just go for "derivative"?

>> 2) bqbiol:isPartOf
>> bqbiol:encompassment, bqbiol:assembly, bqbiol:partship, bqbiol:parthood,
>> bqbiol:whole, bqbiol:meronym
>>
>> Neil favours "parthood". I favour "whole".
> This may be a stupid question, but is it always the case that the thing being referred to is in fact the "whole", as opposed to another subpart within a larger context?  I think it's the latter, and so I think "whole" isn't always going to be the appropriate sense.  I also dislike "parthood".
>
> Would "constituent" be an option here?

I like "constituent", but would propose it as an alternative to "hasPart".
Part/whole would be ok for me.
I also thought about "belonging" which sounds pretty good (X has 
BELONGING Y??).

Dagmar

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Stefan H. <sh...@vb...>]

Hello Dagmar,

I completely agree with you. At least the discussion needs to be 
removed. The problem is how shall we construct the examples especially 
in the view of the proposed changes. I would like the new NOUN versions 
to be used.

Thanks,
Stefan


On 1/17/11 4:47 PM, Dagmar Waltemath wrote:
> Hello everyone,
>
>
> it seems I am the only one complaining about it, but I have to mention it again (sorry ;-)).
> I really find it a mistake to put the qualifiers into the Anot specification...
>
> The reason being that the spec it is an SBML package proposal.
> Therefore, the new qualifiers would be "limited" to SBML people... but they are a biomodels.net concept - and there we always claim not to be tight to SBML.
>
> So, please, could we just refer to qualifiers out of the annot package, like link to the biomodels.net/qualifiers web site
> and leave the rest to the biomodels.net people (who are not too different from this list)?
>
> That will allow others, like CellML people, to use the new qualifiers as well.
>
>
> ...please, if you disagree with me, share you counter arguments with me :-)
> Dagmar
>
> ________________________________________
> From: Neil Swainston [nei...@ma...]
> Sent: 17 January 2011 19:32
> To: Neil Swainston
> Cc: sbm...@li...
> Subject: Re: [sbml-annot] SBML Level 3 Annotation package proposal
>
> Hi all,
>
> Looks like listserv has eaten the document.
>
> Try the following:
>
> ftp://ftp.dbkgroup.org/pub/annot/SBML Level 3 Package Proposal - Annot.doc
>
> Cheers,
>
> Neil.
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
>
> On 17 Jan 2011, at 18:27, Neil Swainston wrote:
>
>> Dear all,
>>
>> Final one from me today...
>>
>> Enclosed is the draft of the SBML Level 3 Annotation package proposal.
>>
>> We've come a long way since the initial meeting, so thanks very much to everyone for their contributions.
>>
>> I'd be very grateful if you could look through the enclosed document, which is essentially the cleaned-up wiki page that we've been editing on the SBML site. Please feel free to add comments, make changes, but please use "Track Changes" on Word so that we can follow the updates.
>>
>> You'll note that Nick Juty's suggestions for new predicates has been added as a table towards the end of the document. Where there are multiple candidates, I've highlighted my personal preference in bold, but obviously this is all open for discussion. Please let me know your preference (if you have one).
>>
>> My intention is to get this finished off and get this submitted to Nature Precedings so that we have a first, fixed version that can be looked over by the SBML Editors. I'd be therefore very grateful if you could make any changes or comments by Friday 28th January.
>>
>> Best wishes,
>>
>> Neil.
>>
>>
>>
>> Neil Swainston
>> Experimental Officer
>>
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>>
>> On 13 Jan 2011, at 13:52, Nicolas Le novère wrote:
>>
>>> On 13/01/11 13:41, Ron Henkel wrote:
>>>> Hi,
>>>>
>>>> How strict is the requirement that a qualifier needs to be a noun (or
>>>> better exactly one noun)?
>>>>
>>>> For example the 'isEncodedBy' qualifier: if we used "encoder" here it
>>>> might be confused, for example, with the person who is the encoder.
>>>>
>>>> So I was thinking if it is possible to use something as "encodingDNA".
>>>> It might ease the finding of proper qualifier terms. Would this still be
>>>> a valid predicate since it is not exactly a noun?
>>>
>>> I think this kind of thing would in principle be fine even if not elegant.
>>> Note that in that case, it would not work because this is not restricted to
>>> DNA. In general I would ban all biological meaning from the qualifiers.
>>>
>>> But I believe you found another candidate: encoding
>>>
>>>> Cheers,
>>>> Ron
>>>>
>>>> On 13.01.2011 14:23, Nick Juty wrote:
>>>>> Dear annotation package people,
>>>>>
>>>>> I thought it would be worth opening up the discussion about BioModels.net qualifiers, in order to start moving forward more earnestly.
>>>>> The premise is that we wish to have qualifiers that follow the "SUBJECT has PREDICATE whose value is OBJECT" statement, and thereby need to convert or
>>>>> add additional qualifiers as nouns, rather than the existing situation where they are verbs.
>>>>>
>>>>> Below is a list of potential candidate equivalents to existing qualifiers found here: http://biomodels.net/qualifiers/
>>>>>
>>>>> In some cases, the noun translation is quite apparent, and in others, not so much ;p I think if we iterate round a little, we can reach a moderate
>>>>> consensus.
>>>>>
>>>>>
>>>>> model-qualifiers
>>>>> ================
>>>>> is =>    'identity'
>>>>> isDescribedBy =>    'description'
>>>>>
>>>>>
>>>>> biology-qualifier
>>>>> ================
>>>>> hasPart =>    'part'
>>>>> hasProperty =>    'property'
>>>>> hasVersion =>    'version', (relates class to instance; animal is a hypernym of cat)
>>>>> is =>    'identity'
>>>>> isDescribedBy =>    'description'
>>>>> isHomologTo =>    'homolog(ue)'
>>>>>
>>>>>
>>>>> The next few are more difficult, and I have collected together candidate 'equivalents'.
>>>>>
>>>>> model-qualifiers:
>>>>> ================
>>>>> 'isDerivedFrom' - needs to reflect modifications to an original model.
>>>>> Candidates: progenitor, antecedent, ancestor, basis, base, foundation, origin
>>>>>
>>>>> biology-qualifiers:
>>>>> ================
>>>>> 'isEncodedBy' - e.g. protein is encoded by DNA
>>>>> Candidates: encoder
>>>>>
>>>>> 'encodes' - e.g. DNA encodes protein
>>>>> Candidates: encodement
>>>>>
>>>>> 'isPartOf' - e.g. subunit A is part of complex B
>>>>> Candidates: encompassment, assembly, partship, parthood, whole, meronym (relates part to whole; finger is a meronym of hand)
>>>>>
>>>>> 'isPropertyOf' - e.g. enzyme activity A is property of entity B
>>>>> Candidates: bearer, carrier,
>>>>>
>>>>> 'isVersionOf' - needs to convey the sense of belonging to some class
>>>>> Candidates: consociate, cohort, superclass, hyponym (relates instance to class to; cat is a hyponym of animal)
>>>>>
>>>>> 'occursIn' - may be sensible to split it into 'physical containment' and 'taxonomic instantiation' types.
>>>>> We could use 'encompassment' or 'containment' ('container'), for the physical type, and 'instantiation' for occurrence in a species.
>>>>>
>>>>> I'd appreciate your thoughts on these, and also on other qualifiers you guys have in mind.
>>>>>
>>>>> cheers,
>>>>>
>>>>> Nick
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how you
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________
>>>>> Sbml-annot mailing list
>>>>> Sbm...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>
>>>
>>>
>>> --
>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot


-- 
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax:   (540) 231-2606
Email: sh...@vb...

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Neil S. <nei...@ma...>]

Hi Stefan,

I agree with this. I was very keen to prevent us from generating both an RDF package, and a non-RDF package, which was originally suggested but since withdrawn. This is why I suggested keeping to RDF, even if it would be RDF-lite (RDFa).

My point with suggesting RDFa is that it is more accessible to developers. The majority of tools don't support annotation. I'm asking why this is.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 18 Jan 2011, at 20:27, Stefan Hoops wrote:

> Hello All,
> 
> On 1/17/11 11:00 AM, Nicolas Le novère wrote:
>>> Essentially, I'm not following your point on abandoning RDF when it comes
>>> to specifying literals such as molecular weight or whatever. I'd have
>>> thought that adding an entirely new way of specifying these independently
>>> of RDF would be confusing.
> >
>> I bow. RDFa would be the way to go.
>> 
> 
> I am actually not following here. Why do we need 2 ways to describe properties.
> 
> 1) The annotation package using full-featured RDF
> 2) RDFa borrowed from html
> 
> The first can completely describe everything the second encodes and more.
> 
> Thanks,
> Stefan
> 
> 
> -- 
> Stefan Hoops, Ph.D.
> Senior Project Associate
> Virginia Bioinformatics Institute - 0477
> Virginia Tech
> Bioinformatics Facility II
> Blacksburg, Va 24061, USA
> 
> Phone: (540) 231-1799
> Fax:   (540) 231-2606
> Email: sh...@vb...

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Stefan H. <sh...@vb...>]

Hello All,

On 1/17/11 11:00 AM, Nicolas Le novère wrote:
>> Essentially, I'm not following your point on abandoning RDF when it comes
>> to specifying literals such as molecular weight or whatever. I'd have
>> thought that adding an entirely new way of specifying these independently
>> of RDF would be confusing.
 >
> I bow. RDFa would be the way to go.
>

I am actually not following here. Why do we need 2 ways to describe 
properties.

1) The annotation package using full-featured RDF
2) RDFa borrowed from html

The first can completely describe everything the second encodes and more.

Thanks,
Stefan


-- 
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax:   (540) 231-2606
Email: sh...@vb...