[DAS] [Fwd: Re: Writeback implementation]
Andy Jenkinson
andy.jenkinson at ebi.ac.uk
Wed Oct 29 19:04:39 UTC 2008
The difference between an ID and a URI is not so great, any ID can be a
URI if we refer to the URN definition. But whether this URI should be
resolvable (that is, a URL) is a big question. Whilst it is certainly a
nice thing to be able to do, I'm not convinced of the practicality given
the relationship between simplicity and adoption of technologies like DAS.
Ignoring the difficulty in making something actually resolvable (which
can potentially be accomplished for features by just having
"http://server/das/source/features?feature_id=foo") there is more
pressure than ever on keeping verbosity low, and I'm not sure if this
can be accomplished as things are right now when you have different URI
prefixes in the same document. Gregg, perhaps you can elaborate?
I know you also advocate alternative content negotiation to solve this
issue - do your alternative formats contain these URIs or do they strip
them?
Gregg Helt wrote:
> Using the DAS/2.0 specification, this idea of "annotations of
> annotations" is easy to do. That's because every feature in DAS/2.0 has
> a unique URI and is therefore addressable by _any_ other system that
> uses URIs -- including another DAS/2.0 server:
>
> <FEATURE uri="http://somewhere.else/feat123" ... >
> <PROP key="my_thoughts_on_feat123" value="overexpressed in tissue
> XYZ" />
> </FEATURE>
>
> Or if you prefer allowing your meta-annotation to have it's own URI:
>
> <FEATURE uri="http//my.server/feat123" ... >
> <PROP key="my_thoughts" value="overexpressed in tissue XYZ" />
> <LINK href="http://somewhere.else/feat123" rev="meta-annotation" />
> </FEATURE>
>
> Used in this way DAS/2.0 becomes very RDF-like..
>
> This is not just a happy accident but the result of a central tenet of
> DAS/2 -- addressability of all important DAS/2 entities outside the
> local system via URIs. The DAS/2 writeback spec is built on top of the
> DAS/2 retrieval spec, so if you're fully implementing the writeback spec
> you should be able to use this ability to do meta-annotations.
>
> Gregg
>
> P.S. It's great to see development starting up again on DAS writeback!
>
> On Wed, Oct 29, 2008 at 8:23 AM, Andy Jenkinson
> <andy.jenkinson at ebi.ac.uk <mailto:andy.jenkinson at ebi.ac.uk>> wrote:
>
> Forgot to send this to the list...
>
> -------- Original Message --------
> Subject: Re: [DAS] Writeback implementation
> Date: Wed, 29 Oct 2008 09:56:53 +0000
> From: Andy Jenkinson <andy.jenkinson at ebi.ac.uk
> <mailto:andy.jenkinson at ebi.ac.uk>>
> Organisation: European Bioinformatics Institute
> To: Gustavo Salazar <gustavo at nbn.ac.za <mailto:gustavo at nbn.ac.za>>
> References: <49058C89.7050301 at nbn.ac.za
> <mailto:49058C89.7050301 at nbn.ac.za>>
>
> Hi Gustavo,
>
> The decentralised 'annotations of annotations' approach is a direction
> that is likely to see most adoption in my opinion because it doesn't
> require the original data provider to modify their source.
>
> Were you planning on using the existing "features" command in order to
> retrieve the annotations, or something else? I ask because it's feasible
> to imagine a DAS source that does not support writeback but still
> annotates another source's annotations. In fact the DASMI architecture
> already does this with it's scoring servers.
>
> Cheers,
> Andy
>
> Gustavo Salazar wrote:
>
> Hello everybody,
>
> This is my first post in this list, therefore I'm going to start
> to introduce myself. I'm Gustavo Salazar, I'm currently busy
> doing my MSc degree in computer science in the University of
> Cape Town - South Africa.
> The project that I'm working on is about the implementation of
> the writeback capabilities in the DAS client Dasty.
> My original Idea was to use as a server the writeback
> implementation created by Asia and Andreas. However i've been
> notice that this implementation works as an extra server and
> Dazzle is kind of middleman between the clients and the
> writeback (am I wrong?) which sound like a good idea in terms of
> independence, but it looks to me that it will be hard for a
> client to identify if a feature is original or has been edited.
> That's why I decided to explore others alternatives and now I
> started to work reimplementing the server DAS writeback
> capabilities not in Dazzle but in MyDas.
> I thing the writeback server should works as a meta-annotation
> server, which means that none of the modifications, additions or
> deletions will be actually changing the original server. in such
> a way a DAS client should see the information of the writeback
> as an extra layer, therefore it should first query regular DAS
> servers, built in memory the graphic, and at the end it will
> query the writeback server to modify this graphic with the
> community information.
> In this way the user can choose to use the wb information or not.
> I will use the protocol as in
> http://biodas.org/documents/das2/das2_writeback.html with the
> modifications that appears in the Asia's Theses. which implies
> the use of OpenId as the authorization system, I agree with the
> pros and and cons of OpenId that Andy posted, therefore if the
> consensus is to use another authorization system I will adapt my
> implementation.
> I will appreciate any comment or suggestions or if anybody wants
> more details of my ideas please no hesitate in ask me.
>
> Regards,
>
> --
> Gustavo Salazar
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org <mailto:DAS at lists.open-bio.org>
> http://lists.open-bio.org/mailman/listinfo/das
>
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org <mailto:DAS at lists.open-bio.org>
> http://lists.open-bio.org/mailman/listinfo/das
>
>
More information about the DAS
mailing list