ppy/chat-transcript_edited_20111018b.txt



PeterYim: Welcome to the

= Open Ontology Repository (OOR) Session - Tue 2011_10_18 =

Topic: OOR Metadata Workshop-IV

Session Chair: MichaelGruninger  

Session page: http://ontolog.cim3.net/cgi-bin/wiki.pl?OOR/ConferenceCall_2011_10_18

.
== Proceedings: ==

.

anonymous morphed into TimWilson

TimWilson: Hi, this is Tim Wilson.  I am having work done in my basement, it is very noisy.

MichaelGruninger: I am having trouble connecting by phone

Tim Darr: Joining ...

PeterYim: are you trying to connect via skype?

PeterYim: Michael got in!

ToddSchneider: Michael, What's a 'module'?

anonymous morphed into NikkiaAnderson

anonymous morphed into AliHashemi

ToddSchneider / MichaelGruninger: Manchester's TONES repository - http://owl.cs.manchester.ac.uk/repository/browser

MichaelGruninger: how ontologies relate to one another elevates OOR from being "just a library of ontologies" (e.g. if you look at TONES from Manchester, that is a large list of ontologies with no interaction between them)

AliHashemi: Scenario:
Given:
Ontology O1 in OWL (in OOR)
Ontology O2 in CL (not in OOR)
Ontology O3 in CL (in OOR) <-- (previously: "ORR" - typo corrected)

Declare in OMV:
O3 hasImport O1
O3 hasImport O2
O1 hasLanguage OWL
O2 hasLanguage CL
O3 hasLanguage CL

===========

AliHashemi: ORR is a typo meant OOR

TimWilson: At my work, ORR is Operational Readiness Review.

PeterYim: There is actually an "ORR" - the MMI project's Ontology Registry and Repository (which is also BioPortal based) - see: http://mmisw.org/orr/#b

If ontologies are located externally to OOR
How to handle this in a workflow tool?

Speak to a need to differentiate between Ontologies that are registered (and axioms are available on OOR)

MichaelGruninger: Using the notion of importing ontologies, there will exist a set of ontologies that are imported by other ontologies but which do not themselves import any others. Such ontologies would be "building block" modules, and we would require them to be registered in the repository.

AliHashemi: hasImport --> useImports*

TimWilson: (Very interesting discussion, but I need to go.)

TerryLongstreth: The notion of imports entrains a responsibility on the part of the OOR services to validate the imported items

TerryLongstreth: Once validated, the imported ontology module is presumed to be an invariant

ToddSchneider: OOR will automatically parse import statements and check for the presence of the ontologies to be imported in OORs.

ToddSchneider: Terry, invariant? With respect to what?

TerryLongstreth: With respect to the importing object

AliHashemi: If you're building services in the OOR to exploit elements of an ontology, if it is not in (or transparent to) the system you can't really deploy the services

TerryLongstreth: If the imported, validated module can change, than everything that imports it can be invalidated

AliHashemi: (I've got to run. Bye.)

TerryLongstreth: ...at some arbitrary time in the future

ToddSchneider: (Sorry, but have to go.)

MichaelGruninger: How does BioPortal capture the notion of different ontology versions and the possibility of new  versions being used which are not part of BioPortal?

TerryLongstreth: How does Bioportal reflect changes in semantics of medical ideas?

KenBaclawski: There are two different notions of import.  One can import an ontology with no specification of which version is being imported.  One could also have a strict import that requires the imported ontology to be a specific version.  One can enforce a strict import by specifying a checksum.

MichaelGruninger: Find examples within BioPortal of one ontology importing another ontology, either internal or external to BioPortal

PeterYim: MichaelGruninger: at the next workshop, we can put some focus on "versioning"

MichaelGruninger: Action Item (for everyone): find papers on ontology versioning

PeterYim: -- session ended: 10:05 am PDT --

---------