Versions Compared

Old Version 32

changes.mady.by.user Former user

Saved on

compared with

New Version 33

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: updated design based on data integration discussion

...

This is a living document to include any and all design issues/questions that crop up in tDAR. The hope is to grow this into an actual spec / design document from the bottom up. 

Mapping values to nodes in an ontology

Primary use case: enable the creation of a mapping template from change the basis for mapping string values to ontology nodes from the data table column to live in a coding sheet to an ontology.  This way the association of .  Associating a coding sheet with a data table column with a coding sheet can bring in all those mappings by default.  However, those mappings may need to be customized (without changing the coding sheet's default mappings).to translate it then brings in all the value to ontology node mappings.  

Thus, there will soon be a two primary ways to create a "mapping template":

  1. Directly from a coding sheet by associating an ontology with that coding sheet
  2. Directly from a data table column by associating an ontology with that data table column

...

  1. with the data table column (Note: this should be exclusive so you can associate only one supporting resource with a data table column - a coding sheet or an ontology).  Behind the scenes this will create an identity coding sheet to house the integration template / mappings.
Unresolved questions:
  1. What happens if we change the coding sheet's mappings after it's been linked?  Should those changes be propagated transparently to all directly linked data table columns (this is currently the default programmatic behavior for simplicity)
    1. Anytime customization of the mappings occurs (by directly editing the data value <=> ontology node mappings) this will copy over all the mappings from the coding sheet mapping template and create a new one unique to that data table column.  Should changes to the parent coding sheet mappings propagate downwards to this customized clone?
    Degenerate data scenarios - if someone associates an ontology-mapped coding sheet with a data table column and then associates another, different ontology with that data table column, what is reasonable default behavior?  Right now we are leaning towards letting the direct ontology on the data table column "win", that is to say, override the coding sheet mappings?
    1. The short answer: yes.  We can do some additional work to support versioning of coding sheets, etc.  

Publishing Ontologies

How should we set up our ontology URIs, and do we need to publish them online somewhere, e.g., http://www.tdar.org/ontology/<resource-id>/<resource-title>#Artiodactyla ?  

...