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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Organisation: European Bioinformatics Institute
To: Gustavo Salazar <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
References: <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
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
[email protected] <mailto:[email protected]>
http://lists.open-bio.org/mailman/listinfo/das
_______________________________________________
DAS mailing list
[email protected] <mailto:[email protected]>
http://lists.open-bio.org/mailman/listinfo/das
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
