[DAS2] Spec issues
Andrew Dalke
dalke at dalkescientific.com
Mon Nov 14 17:30:07 UTC 2005
On Nov 4 Steve wrote:
> <FEATURE das:id="feature/cTel54X.1.2"
> das:type="type/curated_exon">
> <PROP das:ptype="property/genefinder-score">29</PROP>
> <PROP das:ptype="das:prop#phase">2</PROP>
> <PROP das:ptype="das:prop#protein_translation"
> xlink:type="simple"
>
> xlink:href="http://www.wormbase.org/das/protein/volvox/2/feature/
> CTEL54X.1
> />
> </FEATURE>
I think we're missing something. This is XML. We can do
<TYPES xml:base="http://www.wormbase.org/dase/genome/volvox/1/type">
<TYPE id="curated_gene"
ontology="http://song.sf.net/ontologies/sofa#gene"
source="curated"
xml:base="gene/">
<das:ptype name="property/genefinder-score">29</das:ptype>
<das:phase>2</das:phase>
<das:protein_translation xlink:type="simple"
xlink:href="http://www.wormbase.org/..." />
<xyz:ack type="html">This message brought to you by
AT&T</xyz:ack>
</TYPE
</TYPES>
The whole point of having namespaces in XML is to keep from needing
to define new namespaces like <PROP>.
In doing that, there's no problem in supporting things like "bg:glyph",
etc. because the values are expanded as expected by the XML processor.
> Also, we might want to allow some controlled vocabulary terms to be
> used for
> the value of type.source (e.g., "das:curated"), to ensure that
> different
> users use the same term to specify that a feature type is produced by
> curation.
I talked with Andreas Prlic about what other metadata is needed for the
registry system. He mentioned
Together with the BioSapiens DAS people we recently decided that
there should be the possibility to assign gene-ontology evidence
codes to each das source, so in the next update of the registry,
this will be changed.
That's at the source level, but perhaps it's also needed at the
annotation level.
> The spec also seems alarmed by the existence of a xml:base attribute
> in the
> TYPE element. The idea is that any relative URL within this element
> would be
> resolved using that element's xml:base attribute. How would folks be
> with
> having the DAS/2 spec fully support the XML Base spec (
> http://www.w3.org/TR/xmlbase/ )? The result of this would be to add an
> optional xml:base attribute to all elements that contain URLs or
> subelements
> with URLs.
In my reading it seems that xml:base should be included wherever. See
http://norman.walsh.name/2005/04/01/xinclude
> Ugh. In the short term, I think there's only one answer: update your
> schemas to allow xml:base either (a) everywhere or (b) everywhere you
> want XInclude to be allowed. I urge you to put it everywhere as your
> users are likely to want to do things you never imagined. ¶
>
> Description: Properties are typed using the ptype attribute. The value
> of
> the property may be indicated by a URL given by the href attribute, or
> may
> be given inline as the CDATA content of the <PROP> section.
>
> <FEATURES xml:base="http://www.wormbase.org/das/genome/volvox/1/">
> <FEATURE id="feature/cTel54X.1.2"
> type="type/curated_exon">
> <PROP ptype="property/genefinder-score">29</PROP>
> <PROP ptype="das:phase">2</PROP>
> <PROP ptype="property/protein_translation"
> href="/das/protein/volvox/2/feature/CTEL54X.1" />
> </FEATURE>
> </FEATURES>
>
> So in contrast to the TYPE properties which are restricted to being
> simple
> string-based key:value pairs, FEATURE properties can be more complex,
> which
> seems reasonable, given the wild world of features. We might consider
> using
> 'key' rather than 'ptype' for FEATURE properties, for consistency with
> TYPE
> prop elements (however, read on).
My thoughts on these are:
- come up with a more consistent way to store key/value data
- the Atom spec has a nice way to say "the data is in this CDATA
as text/html/xml" vs. "this text is over there". I want to copy its
way of doing things.
- I'm still not clear about xlink. Another is the HTML-style
<link href="http://..." rel="...">
Atom uses the "rel=" to encoding information about the link. For
example, the URL to edit a given document is
<link ... rel="service.edit">
See http://atomenabled.org/developers/api/atom-api-spec.php
Andrew
dalke at dalkescientific.com
More information about the DAS2
mailing list