search

Display-Lab / psdo

Performance Summary Display Ontology
https://display-lab.github.io/psdo/
Other
3 stars 3 forks source link

Add Classes #160

Closed CooperStansbury closed 5 years ago

CooperStansbury commented 5 years ago

Summary of changes:

  1. Added 'single element' roles so we can describe individual elements within a dimension and the dimension itself as the multiset of those elements.
  2. Added a small import file with graph subclasses from STATO. These classes give us many defined graph types, including axis definitions.
  3. Added a few channels based on Munzner to increase the representative power of the mark - channel design pattern.
  4. Created a new release.

@grosscol no squash necessary if changes look good.

CooperStansbury commented 5 years ago

@grosscol two ideas for a fix, leaning towards (1).

  1. Maintain imported terms in our active ontology - rely on applications to resolve purls that exist in the owl file via owl:imports.

    • pros: easy with small number of imported classes/ontologies (currently the case).
    • cons: less friendly as import ecosystem grows/becomes more complex.

  2. Use the psdo-edit.owl and psdo.owl paradigm. Maintain a 'developer' file in the repo (psdo-edit.owl) and resolve import chain as part of the release process. psdo.owl would contain all classes from all import sources. Applications resolve purls in that file, but can ignore owl:imports.

    • pros: single file contains all purls.
    • cons: requires maintaining a development file and a current release file.
grosscol commented 5 years ago

Maintaining copies of the imported terms to avoid using owl:import is one way to go.

  1. The terms must be kept up to do date OR allowed to go stale.
  2. Either way, will cause conflicts with versioning as we have not way of indicating that we meant BFO:0000050 from v1.2 not BFO:0000050 from version 1.4

I don't really understand what the ontology-edit.owl and ontology.owl solved. My impression was that having a master branch and development branches solves most of what that -edit system has been used for.

Alternatively just use catalog to point all imports at a single file for local development.

You could make a mireot of all the terms you're using from other ontologies and stuff that into a file, imports/dev-references.owl and in your catalog, point every single import to that file. Importing BFO, go load imports/dev-references.owl. Importing MFO? go load imports/dev-references.owl. In this way, the psdo.owl just has plain old imports. That lets those get resolved however the consumer sees fit. Maybe they have a local cache or they do some pre-processing or whatever.

It lets you develop against a single small dependency graph and that speeds up your local work with nobody looking at psdo.owl being any the wiser. Unless they read your imports/readme.md file or something of that nature.