Skip to end of metadata
Go to start of metadata

Monday March 1, 2021, 10 AM US Eastern Time

Connection Info

See #ontology in vivo-slack for link.  To join vivo-slack, go to http://bit.ly/vivo-slack 

Resources

Ontology Interest Group Google Folder https://drive.google.com/drive/u/0/folders/1RGBh4fDZdzpJdwyiUMO8OPWwkcmVYrI0

Google Doc for meeting notes:  https://bit.ly/3sCfHz5

VIVO Ontologies on Github:  https://github/vivo-ontolgy 

OBO Slack https://join.slack.com/t/obo-communitygroup/shared_invite/zt-kpkvg7x3-kz7DeGoYKiY~VGWKO0voQg

Attendees

Agenda

  1. Work in Progress
    1. AEON - https://github.com/tibonto/aeon
    2. LANG – https://github.com/vivo-community/language-ontology
    3. ORG – https://github.com/mconlon17/organization-ontology
    4. ADO - https://github.com/vivo-ontologies/academic-degree-ontology
    5. IDO – https://github.com/mconlon17/identifier-ontology
  2. Identifiers
  3. Next meeting: March 15 (time zone issues!)

Notes

  • Philip shares his process on the AEON ontology. 
    • Philip is in the making of implementing suggested object property changes from Mike's review.
      • We need functional "helper" classes & object properties, to be able to map the data contained in external databases that don't support the indirect BFO pattern (ro:has role some (aeon:contributor role and bfo:'realized in' some obi:'planned process').
        • Add functional subclasses to ncbit:'Homo Sapiens', obi:organization and bfo:'material entity', in order to name the nodes (=contributors) that are eqivalent to the general logic of.  
        • Fix the functional aeon:'has contributor' subproperties of ro:'has participant' similar to above, in order to name the edges (=has contributor & sub OPs). 
          • Set the range of these functional properties to the functional sublcasses.
        • If it is possible, these two steps should be generalised and automated using Taking shortcuts with OWL using safe macros. → probably done later (nice to have high level dev task)
    • ToDo
      • v0.3.0 = above described changes implemented
      • v0.4.0 = complete annotations for all terms: definitions, examples, elucidation, term editor, mark the ones that need to be replaced by external ontology later
      • v0.5.0 = Data properties need to be complemented with classes to be able to make statements about them later
      • v0.6.0 = have all most common mappings done using SKOS annotations (DataCite, OpenResearch, DBLP, WikiCFP, GND, Wikidata, Microsoft Scolar)
      • v0.7.0 = integrate needed terms from IDO, LANG & ORG
      • v0.8.0 = last big revision before v1 release (ask Christoph Lange & Lars Vogt?)
      • v0.9.0 = have persistent namespace set up (OSL service at TIB) 
      • v1.0.0 = refactor term IDs to have ranges for similar terms? (better to start early to get a good range management for further distributed development.) Would mean no backwards compatibility!
      • write paper to publish AEON with Mike?, Christian, Christoph Lange & Lars Vogt?
  • Dicussion about IDO
    • Open questions on how to deal with identifiers
      • Are identifiers registered or assigned?
        • They are minted in the dubbing (denoting) process by its participants, who have various degrees of authority in this dubbing process → centrally registered or distributed identifiers
          • But can we really generalize these various degrees of authority? E.g. 'drivers license number' might be registered against a central authority/registry in Germany or Europe
      • What's interesting about Orgs who provide IDs, a) Authority and b) Metadata. 
      • Identifier registration is often times distributed between different parties, even if it is a central ID. Example: DOI, Twitter handle
      • long discussion about handling of IDs, namespaces and resolvable URIs. Which components do we need?
        • Philip: Can we have subclasses of IRI (e.g. URI scheme & URI authortiy) as parts of those IDs which are resolvable online in a subclass expressions similar to CRIDs having as parts CRID symbol & CRID registry?
          • The actual, literal base URIs of such resolvable IDs could then maybe provided as distinct individuals to the ID class (e.g. "http://dx.doi.org/" & "https://doi.org/" for DOI)
    • ToDo next