Questions on use and scope of IAO
Chris Mungall
up. I have a couple of questions, the first few concerning practical
use of IAO, the others concerning the scope of IAO
* Use of IAO
It appears that OBI, RNAO and possibly other ontologies are using IAO
URIs for ontology metadata: synonyms, definitions, etc. This makes a
certain amount of sense from an ontological point of view, but it
seems a little impractical. The intention is presumably that IAO is
imported by any ontology that uses it (which is what OBI does). But
presumably IAO will become quite massive. This means that any ontology
that needs to be a good citizen and re-use the URI for 'synonym' must
also make a large number of ontological commitments about unrelated
information artefacts. Also, most toolchains will end up loading all
of IAO into memory which would typically not be desirable. Perhaps the
intention is to MIREOT the relevant properties in? Sorry if this is
answered in a FAQ somewhere, I couldn't find any information on this.
One possibly minor objection is the use of opaque numeric identifiers
for ontological metadata aretfacts such as the property 'alternative
term'. I am of course a massive fan of meaningless numeric identifiers
- for classes and objectproperties - for annotation properties this
seems to be pushing things a bit further, possibly too far.
Another reason not to try and over-ontologize ontology metadata is the
decision to use owl annotation properties to represent them. This
means (AFAIK) we cannot have any axioms about them, we can't have sub-
properties, etc.
I would have preferred to see ontology metadata live as annotation
properties in a separate lightweight ontology that can be easily
imported. The IAO would be free to have more detailed axioms
concerning object property and class counterparts of these annotation
properties. This seems to be partly the strategy with certain IAO
classes such as 'label' which presumably have annotation property
counterparts.
* Scope of IAO
I can't find any information on the scope of IAO. The intention is
presumably to go quite deep judging by existing classes such as 'lot
number'. The current scope also seems to be very broad judging by the
current contents, which range from ontology metadata through images,
software etc.
I am wondering why the decision was made to have one large ontology
rather than separate ontologies broken down on lines such as the
following:
* lexical and terminological artefacts
* image artefacts
* biblioraphic artefacts
* software artefacts
* measurement, data and statistical artefacts
* legal artefacts
etc
Perhaps with an upper information artefact entity ontology (UIAEO?) to
bind them
Gwen Frishkoff
Dear Chris, et al. --
I'm glad to see this issue addressed. While I might parse the IAO domain
a little differently, I agree whole-heartedly with the suggestion to
separate out an upper (or mid-level) IAO ontology from the subdomains
that comprise domain-specific types of information artifacts (e.g.,
publications, legal_artifacts, etc.).
I had a similar thought after our conf call this morning: maybe specific
document types (e.g., pubs and related concepts) should constitute a
separate module? However, note that document types, as proposed by Larry
H., span several of the modules that you (Chris) propose:
lexical_artifacts, bibliographic_artifacts, legal_artifacts (at least).
I'm a newcomer to this business, but in my view, IAO would be of
greatest utility if it were kept relatively small (4-5 levels?), so it
could serve as a robust mid-level ontology.
My two cents,
Gwen
>
> * Scope of IAO
>
> I can't find any information on the scope of IAO. The intention is
> presumably to go quite deep judging by existing classes such as 'lot
> number'. The current scope also seems to be very broad judging by the
> current contents, which range from ontology metadata through images,
> software etc.
>
> I am wondering why the decision was made to have one large ontology
> rather than separate ontologies broken down on lines such as the
> following:
>
> * lexical and terminological artefacts
> * image artefacts
> * biblioraphic artefacts
> * software artefacts
> * measurement, data and statistical artefacts
> * legal artefacts
> etc
>
> Perhaps with an upper information artefact entity ontology (UIAEO?) to
> bind them
>
>
>
>
Gwen Frishkoff, Ph.D.
Assistant Professor
Department of Psychology
Georgia State University
ph. 414-456-4671 (until Aug 1, 2009)
fax 414-456-6562 (until Aug 1, 2009)
"A speaker is like a lousy auto mechanic: every time he fixes something
in the language, he screws up something else." -- Joseph H. Greenberg
James Malone
There is certainly a lack of explicit and viewable use cases from
which to determine the scope and I think this is something we can do
better. Certainly modularizing IAO would be one option; given their
is no explicit delineation of scope as far as I can see modeling 'all
information' would seem to be it and this is a pretty big task. To
answer Chris' question about splitting into separate files, I think
that there was no conscious decision either way about this but
moreover, that IAO is relatively young and that it just started out
this way. Certainly, since it has grown, I think there is an argument
for splitting it along some of the lines you suggested or at least
having this as a long term possibility if it becomes unwieldy. I like
the idea of an IAO middle-level ontology, although the issue here is
that (at least from an OBI perspective) we need some of the lower
level details otherwise it is not useful to us and furthermore I would
expect the leaf node classes we create would be commonly used (such as
the figures, software).
I agree with your point Chris about ontologizing the annotation
properties for ontology metadata. I never did understand why we
changed from owl properties to classes in OBI (via IAO). No doubt Alan
can answer that :)
James
Alan Ruttenberg
>
> Apologies if I missed some initial discussion here, I'm just catching
> up. I have a couple of questions, the first few concerning practical
> use of IAO, the others concerning the scope of IAO
>
> * Use of IAO
>
> It appears that OBI, RNAO and possibly other ontologies are using IAO
> URIs for ontology metadata: synonyms, definitions, etc. This makes a
> certain amount of sense from an ontological point of view, but it
> seems a little impractical. The intention is presumably that IAO is
> imported by any ontology that uses it (which is what OBI does).
Actually, there is a separated component for ontology metadata,
imported by IAO, called, unsurprisingly, ontology-metadata.owl. It's
URI is http://purl.obolibrary.org/obo/iao/ontology-metadata.owl . The
intention is to have it be self standing. When used alone you can
understand it as using MIREOT to include the few necessary terms from
IAO needed.
> But
> presumably IAO will become quite massive. This means that any ontology
> that needs to be a good citizen and re-use the URI for 'synonym' must
> also make a large number of ontological commitments about unrelated
> information artefacts.
Very few, actually, if you import ontology-metadata only. There is the
assumption that one is using BFO, though it isn't explicitly imported
- we use GenericallyDependentContinuant from BFO, however, and
information content entity and data item from IAO.
Most of the current classes below information about an ontology part
are actually just the oboinowl ones, appropriately placed. I expect
these to mostly be deprecated when we move to OWL 2 and the
application specific reification is no longer needed. Specifically,
Synonym, Definition, Dbxref, at least. Not sure about synonym type,
but if we keep broader/narrower it's probably sensible to use SKOS
terminology for representing these.
> Also, most toolchains will end up loading all
> of IAO into memory which would typically not be desirable. Perhaps the
> intention is to MIREOT the relevant properties in? Sorry if this is
> answered in a FAQ somewhere, I couldn't find any information on this.
No FAQ yet, but this should form one component :)
The intention is to link the standard ontology metadata into OBO, as
we discussed at the first foundry meeting.
Only ontology-metadata would be imported for the typical OWL ontology.
Ontologies that wished to use IAO would make a decision as to whether
they want to import the whole thing or use MIREOT to import selected
terms, as is the choice for any ontology - nothing special about IAO.
> One possibly minor objection is the use of opaque numeric identifiers
> for ontological metadata aretfacts such as the property 'alternative
> term'. I am of course a massive fan of meaningless numeric identifiers
> - for classes and objectproperties - for annotation properties this
> seems to be pushing things a bit further, possibly too far.
I don't see a distinction. An english identifier is opaque to a
non-english speaker and part of the intent of using opaque identifier
is to remove one more element that isn't symmetrically international.
> Another reason not to try and over-ontologize ontology metadata is the
> decision to use owl annotation properties to represent them. This
> means (AFAIK) we cannot have any axioms about them, we can't have sub-
> properties, etc.
We can have OWL Full axioms about them and rules when that technology
comes on line. There is also the ability to declare, within OWL 2,
annotation property domains, ranges, and superproperties. The OWL DL
reasoners won't do anything with these, but the ones based the
RDF-based semantics will. I expect that tools will use them for
presentation (certainly LSW will be modified to take them into
account).
> I would have preferred to see ontology metadata live as annotation
> properties in a separate lightweight ontology that can be easily
> imported.
And so your wish is satisfied with ontology-metadata.owl :)
> The IAO would be free to have more detailed axioms
> concerning object property and class counterparts of these annotation
> properties.
Not obviously necessary atm.
> This seems to be partly the strategy with certain IAO
> classes such as 'label' which presumably have annotation property
> counterparts.
Label is not the same as RDF label. I don't know if I would use labels
for annotations, along the same line of reasoning as you suggest for
keeping things lightweight.
>
> * Scope of IAO
>
> I can't find any information on the scope of IAO. The intention is
> presumably to go quite deep judging by existing classes such as 'lot
> number'. The current scope also seems to be very broad judging by the
> current contents, which range from ontology metadata through images,
> software etc.
This remains to be carefully worked out. Barry would like to see it be
relatively small, and I have a similar sentiment, however I want it to
have enough coverage so that people don't have to invent the
principles needed to represent the variety of situations needed. I've
been calling it a mid-level ontology. Note that not all terms that are
currently in IAO will remain there - on my task list is splitting off
terms that belong in OBI.
Since you are now a member of the project ;-) you have some say in this.
> I am wondering why the decision was made to have one large ontology
> rather than separate ontologies broken down on lines such as the
> following:
>
> * lexical and terminological artefacts
> * image artefacts
> * biblioraphic artefacts
> * software artefacts
> * measurement, data and statistical artefacts
> * legal artefacts
> etc
I would modularize along these lines in any case, setting up a
situation in which users can import those pieces that they want.
That's the intention with OBI - we just haven't got there yet.
I think you nicely partition the important domains that IAO should
cover. I would note that IAO will also include a small set of
processes, roles, and objectives that are relevant in the creation and
consumption of information entities.
Here is how I described the scope of IAO in the tutorial I gave
(slides at http://icbo.buffalo.edu/Presentations/Ruttenberg.pdf)
Aiming to be a mid-level ontology
- Information content entities
- Processes that consume or produce information content entities
- Material bearers of information
- Relations in which one of the relata are information content entities
> Perhaps with an upper information artefact entity ontology (UIAEO?) to
> bind them
Not sure we need separate namespaces, but time will tell.
-Alan
Alan Ruttenberg
> I never did understand why we changed from owl properties to classes in OBI (via IAO). No doubt Alan
> can answer that :)
Indeed I can. We didn't :)
See my note to Chris regarding where Synonym et. al. comes from.
-Alan
James Malone
Do you agree regarding use cases for IAO? At the moment it is a bit
ad hoc, I would prefer to change this strategy lest we be accused by
some of stamp collecting :)
Alan Ruttenberg
> Ah I see. Makes sense.
>
> Do you agree regarding use cases for IAO? At the moment it is a bit
> ad hoc, I would prefer to change this strategy lest we be accused by
> some of stamp collecting :)
It can only help to collect use cases. So let's do that (the wiki
would be a good place ;-) . We have some that come from OBI/DT. I have
a general idea that I want to have it be the basis for the next
generation representation of the CC licenses.
However we're also at a stage of development where we're trying to
expose realist underpinnings of the representation of information
artifacts, and for this some stamp (good use case) collecting is
useful, as it helps us not box ourselves into a (future) corder.
-Alan
Chris Mungall
Thanks a lot for the explanation Alan, this all makes sense.
Some comments inline below
On Jul 29, 2009, at 3:56 AM, Alan Ruttenberg wrote:
> On Tue, Jul 28, 2009 at 7:53 PM, Chris Mungall<c...@berkeleybop.org>
> wrote:
>>
>> Apologies if I missed some initial discussion here, I'm just catching
>> up. I have a couple of questions, the first few concerning practical
>> use of IAO, the others concerning the scope of IAO
>>
>> * Use of IAO
>>
>> It appears that OBI, RNAO and possibly other ontologies are using IAO
>> URIs for ontology metadata: synonyms, definitions, etc. This makes a
>> certain amount of sense from an ontological point of view, but it
>> seems a little impractical. The intention is presumably that IAO is
>> imported by any ontology that uses it (which is what OBI does).
>
> Actually, there is a separated component for ontology metadata,
> imported by IAO, called, unsurprisingly, ontology-metadata.owl. It's
> URI is http://purl.obolibrary.org/obo/iao/ontology-metadata.owl . The
> intention is to have it be self standing. When used alone you can
> understand it as using MIREOT to include the few necessary terms from
> IAO needed.
I had noticed ontology-metadata.owl - what confused me was that
IAO.owl had the annotation properties pseudo-MIREOTed in from ontology-
metadata.owl, so I thought their main declarations were there! Of
course, this is a standard pattern to avoid an ontology looking OWL-
Full to some tools so I should have noticed this.
>> But
>> presumably IAO will become quite massive. This means that any
>> ontology
>> that needs to be a good citizen and re-use the URI for 'synonym' must
>> also make a large number of ontological commitments about unrelated
>> information artefacts.
>
> Very few, actually, if you import ontology-metadata only. There is the
> assumption that one is using BFO, though it isn't explicitly imported
> - we use GenericallyDependentContinuant from BFO, however, and
> information content entity and data item from IAO.
>
> Most of the current classes below information about an ontology part
> are actually just the oboinowl ones, appropriately placed. I expect
> these to mostly be deprecated when we move to OWL 2 and the
> application specific reification is no longer needed. Specifically,
> Synonym, Definition, Dbxref, at least.
am happy to see the old oboInOwl Synonym and DbXref classes go once
OBI switches to OWL2 (background for everyone: these are the result of
an awkward n-ary relations pattern implementation required to
roundtrip obo format metadata. Axiom annotations in OWL2 obviate the
need for this). At the moment it looks kind of odd to see 'Synonym' as
a subclass of 'information about an ontology part' in OBI. But I
expect this will go eventually.
> Not sure about synonym type,
> but if we keep broader/narrower it's probably sensible to use SKOS
> terminology for representing these.
Confusing terminology here, in obo format scope = broader/narrower/
related/exact, type is open ended (e.g. abbreviation,
systematic_synonym, ...)
I would recommend subannotationproperties for scope and tagging axioms
with annotations for type
>
>> Also, most toolchains will end up loading all
>> of IAO into memory which would typically not be desirable. Perhaps
>> the
>> intention is to MIREOT the relevant properties in? Sorry if this is
>> answered in a FAQ somewhere, I couldn't find any information on this.
>
> No FAQ yet, but this should form one component :)
> The intention is to link the standard ontology metadata into OBO, as
> we discussed at the first foundry meeting.
> Only ontology-metadata would be imported for the typical OWL ontology.
> Ontologies that wished to use IAO would make a decision as to whether
> they want to import the whole thing or use MIREOT to import selected
> terms, as is the choice for any ontology - nothing special about IAO.
>
>> One possibly minor objection is the use of opaque numeric identifiers
>> for ontological metadata aretfacts such as the property 'alternative
>> term'. I am of course a massive fan of meaningless numeric
>> identifiers
>> - for classes and objectproperties - for annotation properties this
>> seems to be pushing things a bit further, possibly too far.
>
> I don't see a distinction. An english identifier is opaque to a
> non-english speaker and part of the intent of using opaque identifier
> is to remove one more element that isn't symmetrically international.
By the same token, should we not discontinue using 'IAO', 'GO', 'OBI'
etc and use numbers?
With OWL3 can we expect to see the URI
http://www.w3.org/2002/07/owl#Class
replaced by something like:
http://www.7898723.org/2002/07/0002098#0001677
This will be great, I already love the readability RDF/XML
serialization of OWL, this will make things even better for me and my
fellow machines.
Sorry... I'm only being partially obtuse though - the annotation
properties are the elements of the language we use to represent
reality, rather than the things we care about representing. This is
where the symmetry lies I believe. Of course, we can represent our
representation language, which can be useful, but it's not primarily
what we care about. So the annotation properties live on the side of
the representation, the object properties, classes and instances on
the side of the world.
On a related note, will IAO subsume owl.owl?
no more comments, everything below makes perfect sense, thx
Alan Ruttenberg
comfortable that they have a reasonable home, until they go away.
>
>> Not sure about synonym type,
>> but if we keep broader/narrower it's probably sensible to use SKOS
>> terminology for representing these.
are unfortunate IMO.
>
> Confusing terminology here, in obo format scope = broader/narrower/
> related/exact, type is open ended (e.g. abbreviation,
> systematic_synonym, ...)
>
> I would recommend subannotationproperties for scope and tagging axioms
> with annotations for type
Abbreviations/Systematic synonyms are exact, I think.
>
>>
>>> Also, most toolchains will end up loading all
>>> of IAO into memory which would typically not be desirable. Perhaps
>>> the
>>> intention is to MIREOT the relevant properties in? Sorry if this is
>>> answered in a FAQ somewhere, I couldn't find any information on this.
>>
>> No FAQ yet, but this should form one component :)
>> The intention is to link the standard ontology metadata into OBO, as
>> we discussed at the first foundry meeting.
>> Only ontology-metadata would be imported for the typical OWL ontology.
>> Ontologies that wished to use IAO would make a decision as to whether
>> they want to import the whole thing or use MIREOT to import selected
>> terms, as is the choice for any ontology - nothing special about IAO.
>>
>>> One possibly minor objection is the use of opaque numeric identifiers
>>> for ontological metadata aretfacts such as the property 'alternative
>>> term'. I am of course a massive fan of meaningless numeric
>>> identifiers
>>> - for classes and objectproperties - for annotation properties this
>>> seems to be pushing things a bit further, possibly too far.
>>
>> I don't see a distinction. An english identifier is opaque to a
>> non-english speaker and part of the intent of using opaque identifier
>> is to remove one more element that isn't symmetrically international.
>
> By the same token, should we not discontinue using 'IAO', 'GO', 'OBI'
> etc and use numbers?
acronyms, and without us depending in any way on what the acronyms
mean.
>
> With OWL3 can we expect to see the URI
>
> http://www.w3.org/2002/07/owl#Class
>
> replaced by something like:
>
> http://www.7898723.org/2002/07/0002098#0001677
>
> This will be great, I already love the readability RDF/XML
> serialization of OWL, this will make things even better for me and my
> fellow machines.
>
> Sorry... I'm only being partially obtuse though - the annotation
> properties are the elements of the language we use to represent
> reality, rather than the things we care about representing.
point of view it is no longer justifiable. Once information artifacts
are in the ontology these are clearly they. Seems like a case of
eating our own dog food. "I could be wrong".
> This is
> where the symmetry lies I believe. Of course, we can represent our
> representation language, which can be useful, but it's not primarily
> what we care about. So the annotation properties live on the side of
> the representation, the object properties, classes and instances on
> the side of the world.
world. That's always been the case and to a certain extent the
language used when discussing BFO has been misleading. The question
isn't whether something is in the world. The question is in what
way/portion of the world is it? Information artifacts are in the world
differently then material entities. But they are in the world.
>
> On a related note, will IAO subsume owl.owl?
It's been a deep worry that once we turn self-reflective we are
screwed. We have to monitor this. Of course owl.owl isn't what one
might think it is. It isn't an ontology that describes OWL in the
sense we might. But I hope we don't have to do too much of this sort
of thing (though I fear we will need to do some).
> no more comments, everything below makes perfect sense, thx
-Alan