[DAS2] properties

[Andrew Dalke]

Working more on the property tables.  Here's my understanding
and what I want to do.

Features are of type T and have properties P1, P2, P3, ...

The given 'T' is a URL.  Fetching that gives property information
about the given type Tp1, Tp2, Tp3, ...

The way things are done now, features and types both have
a <PROP> element, though they are different.  Features have
<PROP> elements like

       <PROP  ptype = "/property/genefinder-score">23</PROP>
       <PROP  ptype = "das:phase">0</PROP>

Types have <PROP> elements like

     <PROP key="bg:glyph"     value="box" />
     <PROP key="bg:bgcolor"   value="white" />
     <PROP key="bg:fgcolor"   value="black" />

These will be merged into a single common pattern, which
looks like

   <PROP key="some_name" value="blah" />

(See [1] below)

The key names are string of the form [a-zA-Z_][a-zA-Z0-9_]*

(See [2] below)

In doing this I noticed that feature properties have a URL
but feature type properties do not.  I think this came about
because of the belief that XML namespace definitions (like 'bg:'
in the above example) would expand inside of element
attribute values.

The keys names for these two properties overlap.  That is, a
feature property should override the associated feature type
property.  (For example, "most tRNAscan results are in red
but this particular feature is shown in blue".)

(But see [3] below; stylesheet/view information might better be
stored different from model data.)

There are two options:
   1. make both refer to URLs
      For example, http://www.biodas.org/das2-spec/bgcolor/

   2. make both refer to arbitrary/non-resolvable/opaque identifiers
      For example, define that the string "bgcolor" means
      "background color"

The advantage to the first is automatic determination of
information about the property, as

    <PROPERTY id="bgcolor"
         
ontology="http://song.sourceforge.net/ontologies/feature- 
properties#something1"
        xs:type="assume-there-is-a-color-type"
        xs:ref="http://reference_to_an_xsd_type"
        definition="It's a color"
        doc_href="http://documentation_url"  />

Again though I express my belief that dynamic property lookups
like this are mostly good in theory.  In practice they aren't
that useful to end-user apps.

** I propose that properties are opaque strings with no mapping
to URLs and no way to resolve them to dynamically discover
information about the property.  Instead, standardized properties
are described by a yet-to-be-written document. **

If in the future we decide we need it we can add it in one
of several ways:

   Verbose:

<PROP key="bgcolor" type_href="http://www.biodas.org/das2-spec/bgcolor"
       value="purple" />

   More likely; have "/properties" return a document either describing
the property information directly or mapping the property name into
a resolvable URL which contains the property information.

** Are there any client implementers here who will do anything with
dynamic lookup of the property information? **


[1]: if we need values which are hyperlinks then it should be

   <PROP key="some_name" href="http://blah/" />

and if we want the ability to embed HTML or XML then we can
support something like

   <PROP key="some_name" type="html">Here is &lt;b>XML!&lt;/b></PROP>
   <PROP key="some_name" type="xml"><xhtml:div>Hi!</xhtml:div></PROP>

As there are no current use cases for this I will not put them
into the spec.  I mention them because I think they will be useful.

[2]: We will need a document listing standard properties, like
'bgcolor'.  People working on new properties should use a unique
prefix like 'ABC_' (as in 'ABC_bgcolor').  Basically I'm assuming
there won't be much of a namespace problem.

[3]: But there's still the issue of stylesheets.  Should this
data be directly associated with the data or made available
as an external stylesheet?  HTML stylesheets let you annotate
by class ("feature type") and id (we could use the feature URL),
along with precedence based on stylesheet source.

					Andrew
					dalke at dalkescientific.com