[fitsbits] FITS 'keyword dictionaries'

[Joe Hourcle]

So, to build on the stuff that went around last week, and based on the recommendations from IVOA on using SKOS to represent vocabularies ... here's a short outline of what I'm thinking  ... this is for just trying to document things that already exist, so we don't have to modify existing FITS files.

It's a bit rough, but I wanted to send what I had so far, as I'm getting ready to take leave for the next ~4 weeks, and I'd appreciate any comments, so I can try to refine this before the AAS meeting.  I've cc'd my personal e-mail address (oneiros at annoying.org), which I'll be checking while on leave.

(and for those not familiar with SKOS ... it's the "Simple Knowledge Organization System", an ontology for describing thesauri and other controlled vocabularies;  see http://www.unc.edu/~prjsmith/skos_guide.html for a relatively short explanation of it)

-Joe


...

Standardizing Documentation of FITS Headers:

Scope:

    Attempting to create documentation to describe FITS files
    *without* modifying the FITS files themselves.

    Try to come up with a machine-actionable format that
    can be used by software developers so they don't have to
    do as much work to integrate each mission/instrument.

Things to try to do:

    1. identify which keywords are supposed to be FITS standard,
        which are discipline, mission, instrument, or processing
        specific.
    
    2. Provide units if not explicitly given
    
    3. Identify range of possible values
    
    4. Provide expansion / explanation of enumerations
    
    5. Provide free text to describe how to interpret coded values
        (eg, SDO 'QUALITY'), or for additional details.
        
    6. Identify the autoritative value from a group of similar values.
        (thus identifying which values are derived, and have more error)
        


1. Map concepts in SKOS to recreate the various 'keyword dictionaries'

    KEYWORD:      skos.prefLabel
    REFERENCE:    skos:exactMatch 
    NAME:         skos:[exact|close]Match <associated UCD+> (once UCD is in SKOS)
    EXAMPLE:      skos:example
    DESCRIPTION:  skos:definition

    Extend SKOS where necessary:
    
    STATUS:       fitsKeyword:isRequired
    DEFAULT:      fitsKeyword:defaultValue
    INDEX:        fitsKeyword:indexMin & indexMax
    HDU:          fitsKeyword:hdu
    DATATYPE:     fitsKeyword:valueType
    RANGE:        fitsKeyword:valueMin & valueMax ; stringLength
    VALUE:        (covered by DATATYPE and RANGE)
    UNITS:        fitsKeyword:units
    COMMENT:      fitsKeyword:cardComment


2. Use SKOS to describe semantic relationships [3]

    2.1 Publish SKOS keyword definitions for FITS standard keywords
        + registered conventions

    2.2 For each 'data collection', publish a SKOS list to
        assert which keywords you're using based on other
        standards.
        
        To map between relationships in other schema:
        
            use 'skos:exactMatch' ("concepts can be used interchangeably" [4])
            or, if you're compliant with the definition but adding additional
            assertions 'skos:broadMatch' 
        
            If the concept is the same, but the way the information is
            recorded is different (eg, different date format), use
            'skos:closeMatch' ("sufficiently similar" [4])
        
        To map relationships *within* a given schema:
        
            To identify interchangable keywords, use 'owl:sameAs';
            for differences in encoding or units, use 'owl:equivalentClass'

            use 'skos:Collection' or 'skos:orderedCollection'to group related
            keywords (eg, the WCS keywords for a coordinate system).
            
    2.3 For enumerations (fields where there is a controlled list
        of permitted values), create the list using 'skos:Collection'.

        May need an additional property to relate the keywords to its
        permitted values.


    Unresolved Issues : 

    1.  We need to discuss with members of the semantic community what
        the implications are of using OWL classes or properties for
        keywords.  We currently assume that keywords would be classes.

    2.  This will not correctly identify when groups are using a keyword
        incorrectly (but think they are using it correctly); may require
        peer review of the documentation.

    3.  We may need to have validation to make sure that assertions
        aren't made about ambiguous 'standard' fields, or a way to
        flag potentially problematic keywords.
        
    4.  I am not aware of a way to easily inherit from an entire schema.
        Eg, can you do :
            <InstrumentSchema> skos.broadMatch <MissionSchema>
        ... or do you need to to explicitly name each keyword?
    
    5.  In the case of #4, is it better to explicitly state each
        keyword?

    6.  Should look into what SKOS / VOTable work has been done, as
        they may have some conventions for portions of this.
    


[1] [FITS v3] http://dx.doi.org/10.1051/0004-6361/201015362
[2] [WCS Time] http://hea-www.cfa.harvard.edu/~arots/TimeWCS/
[3] [IVOA Vocab] http://www.ivoa.net/documents/latest/Vocabularies.html
[4] [SKOS] http://www.w3.org/2004/02/skos/