lsid-developer Mailing List for LSID (Life Science Identifier)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

http://www.hugoschwyzer.dreamhosters.com/wp-content/themes/JKtwentyeleven/linko02.php
Does http://lsid-info.org/ no longer exist?

Thanks,

Eddie

From: lsi...@li...
[mailto:lsi...@li...] On Behalf Of Sean
Martin
Sent: October-12-06 2:51 PM
To: pub...@w3...
Cc: Lsi...@li...
Subject: [Lsid-developer] Prototype URL to Life Science Identifier
(LSID)gateway now available

Hello all, 
A little while back the W3C's HCLS BioRDF group (in the form of Susie
Stephens) asked if I would look into establishing a prototype of a gateway
service that allows the mapping of  LSIDs to URLs. The initial suggestion
came from Henry Thompson who asked that we take at look at how the ARK
system does something similar.  He and members of the W3C TAG, as well as
others on the public-semweb-lifesci list have indicated how important they
feel it is that one should be able to derefence URIs using the HTTP URI
scheme and I believe this prototype succeeds in doing just that for LSIDs.
You can read that conversation in the archives of the mail-list [1]. 

The OMG were both interested and willing to cooperate with this effort and
they have established a new DNS domain lsid-info.org for the purpose. I am
pleased to announce that the prototype gateway is now operational. [2] 

 Here is our first stab at the syntax of the mapping. To form your LSID
access URL, replace the string <LSID> with an actual resolvable LSID. 

To retrieve the named bytes use http://lsid-info.org/<LSID> 
        Example:
http://lsid-info.org/urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank:
30350027 

To retrieve the RDF metadata (effectively a named graph) for the named bytes
or concept use http://lsid-info.org/<LSID>? 
        Example:
http://lsid-info.org/urn:lsid:gdb.org:GenomicSegment:GDB132938? 

To retrieve and format the RDF metadata for the named bytes or concept as
human-readable HTML use http://lsid-info.org/rdf2html/<LSID> 
        Example:
http://lsid-info.org/rdf2html/urn:lsid:gene.ucl.ac.uk.lsid.biopathways.org:h
ugo:MVP 

To retrieve information about the authority for the named bytes or concept
use http://lsid-info.org/host/<LSID> 
        Example:
http://lsid-info.org/host/urn:lsid:gdb.org:GenomicSegment:GDB132938 

Obviously this syntax can be evolved so we would like feed back. 

I hope that others will find this gateway as useful as I believe we will.
It may be that early work of this group should focus on establishing
recommendations for and possibly even implementations of how to bridge
useful information that is provided using standards created by non-W3C
organizations and communities to the Semantic Web.  It seems to me that
perhaps we are going to need a number of similar gateways to be established
permanently for other URI schemes like Handle DOIs[3], Oasis XRIs[4] as well
as non-URI  based identifier schemes which provide named bytes and metadata
that is or can be transformed to RDF.  In particular a gateway to the DOI
system would be useful to us at this time because it is widely adopted in
the scientific publishing community and we need a means to uniquely identify
a paper (and indeed an offset into that paper) for the purposes of
annotations stored  in our RDF backed systems. 

Kindest regards, Sean 

[1]
http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006Jul/0213.html 
[2] http://lsid-info.org/ 
[3] http://www.doi.org/ 
[4] http://en.wikipedia.org/wiki/Extensible_Resource_Identifier 
= 

-- 
Sean Martin 
IBM Corp

LSID community members,

A new website has been established at http://lsids.sf.net as the new entry
point for the development of new LSID software and documentation.

The new website is at a different location from the previous Sourceforge
site (lsid.sf.net) as IBM has ceased to support this site. We have added a
trailing 's' for specification or software, while the original site is now
for reference.

The new website includes

* An introduction to LSID and links to more detailed documentation for those
not familiar with the identification scheme and its resolution protocol
* Links to LSID resources, such as LSID software releases and downloads, Rod
Page's LSID authority tester, the TDWG LSID on-line resolver, version
control system and mail lists
* Regularly updated news entries about LSID software, newly deployed
authorities and related information (available as an RSS feed)
* The LSID plug-in for the Firefox browser that enables it to resolve LSIDs
using the lsidres: protocol handler.

A new SourceForge developers website at http://www.sf.net/projects/lsids is
supported by Biodiversity Information Standards (TDWG - www.tdwg.org) and
the Global Biodiversity Information Facility (GBIF - www.gbif.org) and
volunteers. This site features-

* A new release of the LSID Browser for Firefox (v1.0.1) which is available
for download
* A new LSID source code repository and version control system using
Subversion (SVN)

The old developers website (http://www.sf.net/projects/lsid) will maintain:

* All previous major releases of LSID software (such as the client and
server software stacks in Java and Perl),
* The CVS source code repository with all history of LSID software
development (only for reference, as all new development must use the new SVN
repository)
* The issue tracker, and
* The lsid-developer mailing list.

We hope that the new LSID websites will be effective. Questions or
suggestions are welcomed.

Best regards,

Ricardo Pereira
Systems Administrator and Software Engineer 
Biodiversity Information Systems - TDWG

After five years at IBM I am leaving the company to pursue other 
endeavors.  I have enjoyed working with everyone in growing the adoption 
of LSID and making the technology work in real systems.  While IBMs 
involvement and direct support of LSID software, though not endorsement of 
the technology, has come to an end, I imagine we will begin to see new 
organizations continuing to branch  and update various pieces of what we 
made available.  Thank you to everyone who showed patience with the 
development of the LSID client and server stacks as well as the Launchpad 
as our team of very young developers (present company included) attempted 
to change the world, one URI at a time. 

Ben Szekely
IBM Software Engineer
Advanced Internet Technology, Cambridge, MA
bhs...@us...
The latest stuff can be found on lsid.sourceforget.net.  Follow the links=20
to the downloads section.  The tutorials as you wil notice are quite old.=20
The basic concepts in the tutorials haven't changed, but some of the=20
details have such as class names, interfaces etc..I suggest reading the=20
tutorials to get the basic spritit of the system, but then look at the=20
documentation included in the LSID Java Toolkit.

- Ben

Ben Szekely
IBM Software Engineer
Advanced Internet Technology, Cambridge, MA
bhs...@us...

lsi...@li... wrote on 06/20/2007 10:35:30=20
PM:

> Hi,
>=20
>   I was studing LSID mechnism. Where is tutorials about develop=20
> LSID providers?
>=20
> Regards,
>=20
> Guilherme
>=20
>=20
>=20
>=20
>=20
>=20
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Novo Yahoo! Cad=EA? - Experimente uma nova busca.
> http://yahoo.com.br/oqueeuganhocomisso=20
>=20
>=20
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Lsid-developer mailing list
> Lsi...@li...
> https://lists.sourceforge.net/lists/listinfo/lsid-developer

Hi,=0A=0A  I was studing LSID mechnism. Where is tutorials about develop  L=
SID providers?=0A=0ARegards,=0A=0AGuilherme=0A=0A=0A=0A=0A       =0A_______=
___________________________________________________________________________=
__=0ANovo Yahoo! Cad=EA? - Experimente uma nova busca.=0Ahttp://yahoo.com.b=
r/oqueeuganhocomisso 

Greetings,=20

=20

We are working on a project using LSIDs and run into some problems of
resolving our LSID.=20

Our LSID seems working fine with LSID launch pad for IE 6. But it's not
working through biopathways DNS server through Firefox.=20

We can solve this by adding a manual mapping to our server hosting
authority under the options of LSID Browser extension.=20

=20

We are wondering is there anything needed to have the service record for
our lsid to show up in biopathways DNS server? Does anyone have contact
information of Biopathways for this matter?=20

=20

Thanks,=20

=20

Weijia=20

=20

Hi Marcus,

I use LSIDs in my work, and when I started working with them, questions I
had were reasonably quickly answered on this list. However, I too have
noticed the sf website's complete lack of information since its overhaul. I
have no idea who is responsible for the sf pages, but they have been
unfinished for months: the "Lorem ipsum" section is particularly telling...

I don't know of any lists, but I do have a resolution service just for my
lsids running on a tomcat installation. It's not difficult to set up. I
couldn't tell you how big the lsid usage is, or if it is going up or down,
though. Good luck!

On 5/8/07, Marcus Breese <mb...@iu...> wrote:
>
> I've been looking using LSIDs for a while for a project, but I'm curious
> to know how much activity there is with the project.  This mailing list
> doesn't get much traffic, and there are still broken links on the (updated)
> lsid.sf.net site.
>
> How many LSID resolution service are there that are public available, or
> does anyone have a list?
>
> I know that there are a few programs that use LSIDs, but does anyone have
> a guess as to how much traction there is with them?
>
> Thanks,
>
> Marcus Breese
> Indiana University School of Medicine
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Lsid-developer mailing list
> Lsi...@li...
> https://lists.sourceforge.net/lists/listinfo/lsid-developer
>
>

-- 
Thanks,
Allyson :)

Allyson Lister
Research Associate
Centre for Integrated Systems Biology for Ageing and Nutrition
Newcastle University
http://www.cisban.ac.uk
School of Computing Science
Newcastle University
Newcastle upon Tyne, NE1 7RU

I've been looking using LSIDs for a while for a project, but I'm curious to
know how much activity there is with the project.  This mailing list doesn't
get much traffic, and there are still broken links on the (updated)
lsid.sf.net site.

How many LSID resolution service are there that are public available, or
does anyone have a list?

I know that there are a few programs that use LSIDs, but does anyone have a
guess as to how much traction there is with them?

Thanks,

Marcus Breese
Indiana University School of Medicine

はじめまして美樹です。
掲示板で見て趣味合うかなって思ってメールしちゃいました。

イキナリでゴメンなさいm(__)m
こういう感じで知り合えるのに憧れてて初挑戦しちゃいました。
お返事もらえたら簡単な自己紹介しますネ(^_-)-☆
もしそんな気なかったらそう言ってもらえれば諦めますので。
もちろん仲良くなれた方が嬉しいけど。
お返事気長に待ってま〜す(^_^)/~
http://www.itfeelit.com/m-box

Yes, I have noticed this as well. It seems to have been this way for a
couple of months. Before, when I had problems and went off-list, my main
contact was bhs...@us.... Ben is subscribed to this list, though.

thanks,
Allyson

On 3/16/07, Ricardo Pereira <ri...@td...> wrote:
>
>     Hi all,
>
>     I've noticed that the LSID website has a new look and feel and that
> it has been restructured. However, there are a few broken links and some
> placeholder text (Lorem ipsum kind of thing) here and there.
>
>     Does any one know what's up with the website? Who should I contact
> to offer to help fix those problems? The website doesn't make it clear
> who's responsible for it.
>
>     Cheers,
>
> Ricardo Pereira
> Software Engineer
> Biodiversity Information Standards (TDWG)
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net 's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Lsid-developer mailing list
> Lsi...@li...
> https://lists.sourceforge.net/lists/listinfo/lsid-developer
>

-- 
Allyson Lister
Research Associate
Centre for Integrated Systems Biology for Ageing and Nutrition
Newcastle University
http://www.cisban.ac.uk
School of Computing Science
Newcastle University
Newcastle upon Tyne, NE1 7RU

    Hi all,

    I've noticed that the LSID website has a new look and feel and that 
it has been restructured. However, there are a few broken links and some 
placeholder text (Lorem ipsum kind of thing) here and there.

    Does any one know what's up with the website? Who should I contact 
to offer to help fix those problems? The website doesn't make it clear 
who's responsible for it.

    Cheers,

Ricardo Pereira
Software Engineer
Biodiversity Information Standards (TDWG)

Roger Hyam wrote:
> Thanks Tom,
> 
> That is the answer I am looking for. i.e. it is essential for some  
> applications.

It is, but there are ways around it :)

> The problem is that it is very unsafe to return XML (or other text  
> representation) in response to a getData call. The only way to do it  
> is to serialize the data when the LSID is minted and only return that  
> byte stream. This is ugly really as it is like pretending an XML  
> document is really a tiff image.

As Allyson pointed out you don't actually have to resolve all LSIDs 
you've ever allocated. The metadata is free to be volatile, all the 
examples in the original specification assumed this would happen, so you 
have a conceptual object such which only has metadata, this metadata 
points to concrete instantiations of that object. You can then use RDF 
describing the 'latest' or 'most applicable' version without breaking 
the LSID contract.

The primary case we have where we don't want data to change is actually 
publication - if we declare that a workflow ran and produced some 
results and this is part of a paper we need to ensure that the workflow 
definition and the results are actually the ones we talk about in the 
paper when someone looks them up! The above approach allows this to 
happen while still retaining the possibility of updates (so the LSID 
client can come back and say 'this is what smith et al published, but 
there's a later more interesting version as well').

> Allyson's worries are well founded. It is not just changes to the XSD  
> that will break the contract but any white space changes. If a new  
> version of the serializer decides to change the way it does indenting  
> then the thing will not be byte identical. The difference between  
> <foo bar="42"/>  and <foo bar="42" /> breaks it. The XML must really  
> be serialized only once.

This is an annoyance but you can actually fix it by having your 
authority implementation run the XML through its own SAX based pretty 
printer before returning it, that way the XML is guaranteed to be byte 
equivalent for the same document and if you use SAX the processing cost 
is minimal.

> There really is no versioning mechanism in LSIDs. Using the version  
> numbers is just like minting different IDs. If the client manipulates  
> the version numbers then it breaks the opacity of the GUID i.e.  
> implies the client knows how the authority works. Do the versions go  
> 1.1, 1.2, 3.0 or 1.1, 1.2, 1.3? etc. The only safe way to handle  
> versioning is to use the metadata to link between objects so  
> effectively build a linked list for the client to traverse.

It's not quite like creating a new ID, and as I said you're free to 
choose the version scheme. The difference between this and creating an 
entirely novel ID is that clients should expect the two IDs to refer to 
an entity which is at some level 'the same'. This is more of a 
philosophical point than a technical one in some cases but a client 
could reasonably be expected to do this whereas with entirely new IDs 
there's no way to link them. It's also reasonably intuitive to a human 
user that the versions denote an earlier or later instance of the same 
thing which can be handy sometimes. In the case you're describing I'd 
suggest using versions that look like dates because, well, they are.

The other 'special' behaviour is that clients are allowed to request 
resolution of a versioned LSID without specifying the version (can 
someone who's read the spec more recently confirm this?). This means you 
can have a concept of 'latest' according to your version scheme (so last 
update date in this case) and have that always returned but at the same 
time allow the real data to remain immutable. I assume this only applies 
to metadata resolution of course but it's still useful - point to the 
latest version in your metadata (and maybe a list of all historical 
versions if you need that).

> In the biodiversity informatics domain there are very few  
> applications where we will return data in the sense of byte identical  
> streams.

You're far from alone in this - in the case of sensor networks we name 
the sensor rather than the data it produces. It's a question of 'enough 
metadata to do the job' so you don't have to assign unique names to 
everything.

> The requirement for byte identical data rules out much generation of  
> data on the fly. It wouldn't be possible to return a compressed image  
> that is generated from a master for example (does that codec produce  
> the same bytes every time it is run on any hardware?). Any changes to  
> software might result in changes to bytes but not changes in  
> 'meaning' of the data.

This is the intention of abstract LSIDs. You only return metadata, the 
metadata contains a reference to a URI to the current data.

> My worry is that not having this notion of data limits the  
> applicability and therefore adoption of LSIDs.

Sure it does - LSIDs aren't a panacea, there will always be cases where 
they're not appropriate (the next generation of our workflow engine uses 
an internal ID scheme and has the option to publish data to LSID rather 
than using them throughout, for example)

I think there's definite scope for specifying patterns in the metadata 
for the kind of usage you describe as it's fairly common, but I'd rather 
do that than add to the spec in other places. A common practice for 
metadata (which, after a quick browse, appears to be what you guys do 
:)) would make this a lot simpler without requiring updates to clients 
for which this wasn't important.

Tom

Hi Sean,

On 1/25/07, Sean Martin <sj...@us...> wrote:
>
> Hello Allyson,
>
>  >
>  > We also wish to return XML from the getData() calls, and lately I've
>  > been worried about changes to the XSD of the XML format we're using.
>  > What happens if there is a new release of the XSD, which renames
>  > element "foo" to element "bar"? That would change the resolving of
>  > all the LSIDs whose objects contain that problem element. Would I
>  > have to give all of those objects a new version, even though the
>  > information contained in them hasn't changed? I am guessing the
> > answer is yes, but I would be curious to see if anyone else has had
>  > experience in this area. I don't know if the specification allows
>  > for LSIDs that were resolvable to later become unresolvable..., and
>
> The spec certainly allows this. There is no obligation to resolve and serve data for any (even "current") LSIDs - i.e. you can just use it as a name with no resolver. The only obligation is that when/if you first serve out data bytes for an LSID, you never ever serve out any other bytes for the same name.

This makes a lot of sense. I would definitely feel comfortable not
resolving out of date LSIDs (and just providing, as you say, metadata
information on the most recent version), so this sounds like a good
way forward.

Thanks for your suggestions!

Regards,
Allyson

>
>  > in any case that doesn't seem to be a suitable answer for me.
>  > However, having to allow resolution for outdated XML formats seems
>  > like the only way to go - of course, the metadata method can tell
>  > the programmer that they are retrieving an outdated object, and give
>  > them the LSID of the most recent object.
>  >
>  > Does that sound at all sensible?
>
> Yes it does. Although if it were me, I might also consider serving only metadata for the depricated LSIDs pointing to the newer ones and would stop serving data bytes (just provide no data binding) for those that were outdated, unless there was a good reason to continue to provide the out of date ones too.
>
> Kindest regards, Sean

-- 
Allyson Lister
Research Associate
Centre for Integrated Systems Biology for Ageing and Nutrition
Newcastle University
http://www.cisban.ac.uk
School of Computing Science
Newcastle University
Newcastle upon Tyne, NE1 7RU

Hello Allyson,

> 
> We also wish to return XML from the getData() calls, and lately I've
> been worried about changes to the XSD of the XML format we're using.
> What happens if there is a new release of the XSD, which renames 
> element "foo" to element "bar"? That would change the resolving of 
> all the LSIDs whose objects contain that problem element. Would I 
> have to give all of those objects a new version, even though the 
> information contained in them hasn't changed? I am guessing the 
> answer is yes, but I would be curious to see if anyone else has had 
> experience in this area. I don't know if the specification allows 
> for LSIDs that were resolvable to later become unresolvable..., and 

The spec certainly allows this. There is no obligation to resolve and 
serve data for any (even "current") LSIDs - i.e. you can just use it as a 
name with no resolver. The only obligation is that when/if you first serve 
out data bytes for an LSID, you never ever serve out any other bytes for 
the same name. 

> in any case that doesn't seem to be a suitable answer for me. 
> However, having to allow resolution for outdated XML formats seems 
> like the only way to go - of course, the metadata method can tell 
> the programmer that they are retrieving an outdated object, and give
> them the LSID of the most recent object. 
> 
> Does that sound at all sensible?

Yes it does. Although if it were me, I might also consider serving only 
metadata for the depricated LSIDs pointing to the newer ones and would 
stop serving data bytes (just provide no data binding) for those that were 
outdated, unless there was a good reason to continue to provide the out of 
date ones too.

Kindest regards, Sean 
Hi Roger,

lsi...@li... wrote on 01/24/2007 04:46:50 
PM:

> One of the fundamental features of the LSID spec is the fact that 
> the data returned for any LSID must remain byte identical or not be 
> returned at all. I can see the reasoning for this in 
> many disciplines  but I am beginning to find it a pain in the neck 
> for some of the applications we would like to use LSIDs for.
> 
> I was in a meeting recently talking about an XML Schema to handle 
> biographical information of biologists. It would be nice to identify
> a biography with an LSID. It would be good to return some metadata 
>  about the biography in RDF (so that it can be understood by 
> semantic type applications) and then the actual xml text of the 
> biography as the data. This seems like an entirely reasonable thing 
> to do to me because:
> 
> * The biography is basically a text document and a good example of 
> the kind of thing that shouldn't be entirely marked up in RDF. It 
> should really be an XHTML extension or something similar.
> 
> * The biography is data. It would be possible to return it as 
> another format of metadata but then we would have to establish a 
> naming convention that applications would need to know. 
> 
> * To say the biography is metadata about the person seem plain 
> wrong. The LSID is to the biography record not the person.
> 

I can see your problem, but I am fairly certain that the answer is not to 
change what I see as probably the most fundamental property of the LSID 
scheme. As you write, options might (quite reasonably) include getting the 
LSID community to agree a standard for the appropriate metadata required 
to store/retrieve which is the latest version of an LSID and then adding a 
new method that can navigate that metadata (on the server side) to always 
retrieve the latest version e.g.  getMostRecent(LSID) which then figures 
out which is actually the most recent version of the LSID and returns the 
data/metaData for that. 

> Generating an new LSID every time the biography changes seem 
> overkill. 

Since their is no obligation to actually return data for any LSID, out of 
data LSIDs would no longer return anything except metadata pointing the 
latest. As far as I am concerned the cost of a new name (just a unique 
string after all) is very low!

Alternatively for the type of data you describe one might also consider 
using a different URI scheme that has more appropriate restrictions e.g. a 
PURL, since what you seem to really need is permanence of the URI and the 
concept which it stands for, but not permanence of the data. The PURL URI 
scheme seems ideal for that sort of data. Of course using the 
http://lsid-info.org/....  gateway one might be able to combine both the 
LSID and PURL schemes to get the best of both worlds. One could use a PURL 
to always point to a particular LSID (but use the PURL update mechanism to 
change which particular LSID that is over time. As more recent versions of 
the LSID are created you would simply update the PURL pointer for the 
concept to the concrete (and unchanging) LSID version of it. 

A URI is just a URI after all and we have no problem mixing and matching 
them as appropriate to the data/concept named in our work here.

Kindest regards, Sean

Thanks Tom,

That is the answer I am looking for. i.e. it is essential for some  
applications.

The problem is that it is very unsafe to return XML (or other text  
representation) in response to a getData call. The only way to do it  
is to serialize the data when the LSID is minted and only return that  
byte stream. This is ugly really as it is like pretending an XML  
document is really a tiff image.

Allyson's worries are well founded. It is not just changes to the XSD  
that will break the contract but any white space changes. If a new  
version of the serializer decides to change the way it does indenting  
then the thing will not be byte identical. The difference between  
<foo bar="42"/>  and <foo bar="42" /> breaks it. The XML must really  
be serialized only once.

There really is no versioning mechanism in LSIDs. Using the version  
numbers is just like minting different IDs. If the client manipulates  
the version numbers then it breaks the opacity of the GUID i.e.  
implies the client knows how the authority works. Do the versions go  
1.1, 1.2, 3.0 or 1.1, 1.2, 1.3? etc. The only safe way to handle  
versioning is to use the metadata to link between objects so  
effectively build a linked list for the client to traverse.

In the biodiversity informatics domain there are very few  
applications where we will return data in the sense of byte identical  
streams.

The requirement for byte identical data rules out much generation of  
data on the fly. It wouldn't be possible to return a compressed image  
that is generated from a master for example (does that codec produce  
the same bytes every time it is run on any hardware?). Any changes to  
software might result in changes to bytes but not changes in  
'meaning' of the data.

My worry is that not having this notion of data limits the  
applicability and therefore adoption of LSIDs.

Perhaps we need a separate method call. The WSDL could just define a  
getVarData() or something. The metadata could then give a time to  
live for caching and it would not break the notion of getData  
returning something immutable. I guess we could just start doing this  
and if it works the standard could adopt it.

Your thoughts always welcome,

Roger

On 24 Jan 2007, at 21:58, Tom Oinn wrote:

> Roger Hyam wrote:
>> Hi Everyone,
>> One of the fundamental features of the LSID spec is the fact that  
>> the data returned for any LSID must remain byte identical or not  
>> be returned at all. I can see the reasoning for this in many  
>> disciplines  but I am beginning to find it a pain in the neck for  
>> some of the applications we would like to use LSIDs for.
>> I was in a meeting recently talking about an XML Schema to handle  
>> biographical information of biologists. It would be nice to  
>> identify a biography with an LSID. It would be good to return some  
>> metadata  about the biography in RDF (so that it can be understood  
>> by semantic type applications) and then the actual xml text of the  
>> biography as the data. This seems like an entirely reasonable  
>> thing to do to me because:
>> * The biography is basically a text document and a good example of  
>> the kind of thing that shouldn't be entirely marked up in RDF. It  
>> should really be an XHTML extension or something similar.
>> * The biography is data. It would be possible to return it as  
>> another format of metadata but then we would have to establish a  
>> naming convention that applications would need to know. * To say  
>> the biography is metadata about the person seem plain wrong. The  
>> LSID is to the biography record not the person.
>> The trouble is:
>> * An XML document won't be byte identical unless a hack is put in  
>> to stream it to file or similar.
>> * People's biographies change. The subset of biologists that are  
>> alive may progress their careers and will all eventually die -  
>> thus requiring an update to their biographies.
>> So we can't return the biography in the getData call. Generating  
>> an new LSID every time the biography changes seem overkill. For  
>> consistency one would probably have to have an LSID for the  
>> abstract notion of the biography that just returned metadata about  
>> where the latest version was or maintain the old LSIDs with  
>> replacedBy links in the metadata that the client would have to  
>> navigate.
>> There are other examples of where it would be nice to return an  
>> XML document or something else variable as data.
>> Can anyone see a reason why the spec shouldn't be changed in  
>> respect to this feature. Should there be a metadata flag to say  
>> data is variable? It would just make life so much easier!
>
> Please do not change the fundamental nature of LSIDs, this would be  
> a really bad idea[tm]. You can't just change a contract such as  
> immutability and expect everything to carry on working, it's really  
> the most powerful part of the specification for every application  
> I've seen. It would certainly break our provenance capture  
> mechanism and any form of caching such as is done by the default  
> client implementations, so it would be a big big alteration,  
> however...
>
> Sounds to me like you could be using the versioning mechanism  
> though? I mean, that's the whole point of it, to cope with data  
> that has multiple versions... I think generating a new version of  
> the same LSID every time the biography changes is exactly in the  
> spirit of the specification and shouldn't be too onerous - the  
> exact versioning scheme is up to you as well, you could choose to  
> have versions corresponding to dates over time in a certain format  
> which would then give your resolver the ability to serve up the  
> biography for a particular scientist at any moment in time, which  
> is kind of cool.
>
> Off topic, what are you doing with this? We might be very  
> interested as we're currently working on a system called  
> myExperiment to allow users (biologists and bioinformaticians  
> primarily) to share workflow fragments and methodologies in a  
> principled way, a biography component would fit perfectly with what  
> we're working on in that area. Let me know off list if it sounds  
> like there might be an intersection of interests?
>
> Tom (Taverna, myGrid and some other stuff[tm])

Hi Everyone,

I agree with Roger that this can be a problem - our group is also using
LSIDs for our objects, and we do in fact have (non-resolvable) LSIDs for our
"enduring" objects, which then have connections from those objects to our
(resolvable) "versioned" objects - a new LSID for each new version of the
data. This seems to be a useful way of dealing with versioning in our
system, but I have just run into the (as yet theoretical) problem of the
getData() method returning a byte-for-byte match. *Let me just say here I
totally agree with the "permanence" aspect of the object - I think it is
important to always return exactly the same thing - I just have
implementation questions!)

We also wish to return XML from the getData() calls, and lately I've been
worried about changes to the XSD of the XML format we're using. What happens
if there is a new release of the XSD, which renames element "foo" to element
"bar"? That would change the resolving of all the LSIDs whose objects
contain that problem element. Would I have to give all of those objects a
new version, even though the information contained in them hasn't changed? I
am guessing the answer is yes, but I would be curious to see if anyone else
has had experience in this area. I don't know if the specification allows
for LSIDs that were resolvable to later become unresolvable..., and in any
case that doesn't seem to be a suitable answer for me. However, having to
allow resolution for outdated XML formats seems like the only way to go - of
course, the metadata method can tell the programmer that they are retrieving
an outdated object, and give them the LSID of the most recent object.

Does that sound at all sensible?

Thanks,
Allyson

p.s. Tom - I'm thinking about using taverna as an entry point for my
FuGE/CISBAN LSID authority. I may be emailing you in future!

On 1/24/07, Tom Oinn <tm...@eb...> wrote:
>
> Roger Hyam wrote:
> > Hi Everyone,
> >
> > One of the fundamental features of the LSID spec is the fact that the
> > data returned for any LSID must remain byte identical or not be returned
> > at all. I can see the reasoning for this in many disciplines  but I am
> > beginning to find it a pain in the neck for some of the applications we
> > would like to use LSIDs for.
> >
> > I was in a meeting recently talking about an XML Schema to handle
> > biographical information of biologists. It would be nice to identify a
> > biography with an LSID. It would be good to return some metadata  about
> > the biography in RDF (so that it can be understood by semantic type
> > applications) and then the actual xml text of the biography as the data.
> > This seems like an entirely reasonable thing to do to me because:
> >
> > * The biography is basically a text document and a good example of the
> > kind of thing that shouldn't be entirely marked up in RDF. It should
> > really be an XHTML extension or something similar.
> >
> > * The biography is data. It would be possible to return it as another
> > format of metadata but then we would have to establish a naming
> > convention that applications would need to know.
> >
> > * To say the biography is metadata about the person seem plain wrong.
> > The LSID is to the biography record not the person.
> >
> > The trouble is:
> >
> > * An XML document won't be byte identical unless a hack is put in to
> > stream it to file or similar.
> >
> > * People's biographies change. The subset of biologists that are alive
> > may progress their careers and will all eventually die - thus requiring
> > an update to their biographies.
> >
> > So we can't return the biography in the getData call.
> >
> > Generating an new LSID every time the biography changes seem overkill.
> > For consistency one would probably have to have an LSID for the abstract
> > notion of the biography that just returned metadata about where the
> > latest version was or maintain the old LSIDs with replacedBy links in
> > the metadata that the client would have to navigate.
> >
> > There are other examples of where it would be nice to return an XML
> > document or something else variable as data.
> >
> > Can anyone see a reason why the spec shouldn't be changed in respect to
> > this feature. Should there be a metadata flag to say data is variable?
> > It would just make life so much easier!
>
> Please do not change the fundamental nature of LSIDs, this would be a
> really bad idea[tm]. You can't just change a contract such as
> immutability and expect everything to carry on working, it's really the
> most powerful part of the specification for every application I've seen.
> It would certainly break our provenance capture mechanism and any form
> of caching such as is done by the default client implementations, so it
> would be a big big alteration, however...
>
> Sounds to me like you could be using the versioning mechanism though? I
> mean, that's the whole point of it, to cope with data that has multiple
> versions... I think generating a new version of the same LSID every time
> the biography changes is exactly in the spirit of the specification and
> shouldn't be too onerous - the exact versioning scheme is up to you as
> well, you could choose to have versions corresponding to dates over time
> in a certain format which would then give your resolver the ability to
> serve up the biography for a particular scientist at any moment in time,
> which is kind of cool.
>
> Off topic, what are you doing with this? We might be very interested as
> we're currently working on a system called myExperiment to allow users
> (biologists and bioinformaticians primarily) to share workflow fragments
> and methodologies in a principled way, a biography component would fit
> perfectly with what we're working on in that area. Let me know off list
> if it sounds like there might be an intersection of interests?
>
> Tom (Taverna, myGrid and some other stuff[tm])
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Lsid-developer mailing list
> Lsi...@li...
> https://lists.sourceforge.net/lists/listinfo/lsid-developer
>

-- 
Allyson Lister
Research Associate
Centre for Integrated Systems Biology for Ageing and Nutrition
Newcastle University
http://www.cisban.ac.uk
School of Computing Science
Newcastle University
Newcastle upon Tyne, NE1 7RU

Roger Hyam wrote:
> Hi Everyone,
> 
> One of the fundamental features of the LSID spec is the fact that the 
> data returned for any LSID must remain byte identical or not be returned 
> at all. I can see the reasoning for this in many disciplines  but I am 
> beginning to find it a pain in the neck for some of the applications we 
> would like to use LSIDs for.
> 
> I was in a meeting recently talking about an XML Schema to handle 
> biographical information of biologists. It would be nice to identify a 
> biography with an LSID. It would be good to return some metadata  about 
> the biography in RDF (so that it can be understood by semantic type 
> applications) and then the actual xml text of the biography as the data. 
> This seems like an entirely reasonable thing to do to me because:
> 
> * The biography is basically a text document and a good example of the 
> kind of thing that shouldn't be entirely marked up in RDF. It should 
> really be an XHTML extension or something similar.
> 
> * The biography is data. It would be possible to return it as another 
> format of metadata but then we would have to establish a naming 
> convention that applications would need to know. 
> 
> * To say the biography is metadata about the person seem plain wrong. 
> The LSID is to the biography record not the person.
> 
> The trouble is:
> 
> * An XML document won't be byte identical unless a hack is put in to 
> stream it to file or similar.
> 
> * People's biographies change. The subset of biologists that are alive 
> may progress their careers and will all eventually die - thus requiring 
> an update to their biographies.
> 
> So we can't return the biography in the getData call. 
> 
> Generating an new LSID every time the biography changes seem overkill. 
> For consistency one would probably have to have an LSID for the abstract 
> notion of the biography that just returned metadata about where the 
> latest version was or maintain the old LSIDs with replacedBy links in 
> the metadata that the client would have to navigate.
> 
> There are other examples of where it would be nice to return an XML 
> document or something else variable as data.
> 
> Can anyone see a reason why the spec shouldn't be changed in respect to 
> this feature. Should there be a metadata flag to say data is variable? 
> It would just make life so much easier!

Please do not change the fundamental nature of LSIDs, this would be a 
really bad idea[tm]. You can't just change a contract such as 
immutability and expect everything to carry on working, it's really the 
most powerful part of the specification for every application I've seen. 
It would certainly break our provenance capture mechanism and any form 
of caching such as is done by the default client implementations, so it 
would be a big big alteration, however...

Sounds to me like you could be using the versioning mechanism though? I 
mean, that's the whole point of it, to cope with data that has multiple 
versions... I think generating a new version of the same LSID every time 
the biography changes is exactly in the spirit of the specification and 
shouldn't be too onerous - the exact versioning scheme is up to you as 
well, you could choose to have versions corresponding to dates over time 
in a certain format which would then give your resolver the ability to 
serve up the biography for a particular scientist at any moment in time, 
which is kind of cool.

Off topic, what are you doing with this? We might be very interested as 
we're currently working on a system called myExperiment to allow users 
(biologists and bioinformaticians primarily) to share workflow fragments 
and methodologies in a principled way, a biography component would fit 
perfectly with what we're working on in that area. Let me know off list 
if it sounds like there might be an intersection of interests?

Tom (Taverna, myGrid and some other stuff[tm])

Hi Everyone,

One of the fundamental features of the LSID spec is the fact that the  
data returned for any LSID must remain byte identical or not be  
returned at all. I can see the reasoning for this in many  
disciplines  but I am beginning to find it a pain in the neck for  
some of the applications we would like to use LSIDs for.

I was in a meeting recently talking about an XML Schema to handle  
biographical information of biologists. It would be nice to identify  
a biography with an LSID. It would be good to return some metadata   
about the biography in RDF (so that it can be understood by semantic  
type applications) and then the actual xml text of the biography as  
the data. This seems like an entirely reasonable thing to do to me  
because:

* The biography is basically a text document and a good example of  
the kind of thing that shouldn't be entirely marked up in RDF. It  
should really be an XHTML extension or something similar.

* The biography is data. It would be possible to return it as another  
format of metadata but then we would have to establish a naming  
convention that applications would need to know.

* To say the biography is metadata about the person seem plain wrong.  
The LSID is to the biography record not the person.

The trouble is:

* An XML document won't be byte identical unless a hack is put in to  
stream it to file or similar.

* People's biographies change. The subset of biologists that are  
alive may progress their careers and will all eventually die - thus  
requiring an update to their biographies.

So we can't return the biography in the getData call.

Generating an new LSID every time the biography changes seem  
overkill. For consistency one would probably have to have an LSID for  
the abstract notion of the biography that just returned metadata  
about where the latest version was or maintain the old LSIDs with  
replacedBy links in the metadata that the client would have to navigate.

There are other examples of where it would be nice to return an XML  
document or something else variable as data.

Can anyone see a reason why the spec shouldn't be changed in respect  
to this feature. Should there be a metadata flag to say data is  
variable? It would just make life so much easier!

I'd be grateful for your thoughts,

Roger

****************************************
   Roger Hyam <ro...@td...>
   Biodiversity Information Standards
****************************************

Thanks Alyssa,

I guess my request was fairly impossible.

Would it be possible for the plugin to set the browser in a state  
that says "give me initial responsibility for rendering the next link  
you follow". The plugin could then take a look at the stream (or even  
just the header) and decide whether it wanted to handle it or not. I  
have not done any Firefox hacking so may be totally off on this.

Rod's point about adding style sheet instructions to the RDF is a  
good one I think I will follow. I had held off this thinking it would  
'pollute' the vocabularies but now I think it is a necessity people  
come to the vocabs from different directions with their browsers.  
Probably better than having Apache detect the browser etc.

I really wanted to raise the point and see if anyone came up with an  
idea. If I can think of anything implementable I'll have a go at it  
or let you know.

All the best,

Roger

On 4 Jan 2007, at 15:30, Alyssa Wolf wrote:

> Hello Roger,
>
>> It seems clear to me that any LSID client software has to understand
>> URL type URIs and attempt to render them.
>
> The problem with this is these http URLs are not retrieved via the
> lsidres: protocol handler, they're handled by Firefox's native http
> protocol handler which unfortunately does not display RDF in a reader
> friendly manner.  It doesn't really make sense for the firefox  
> plugin to
> assume all http URLs are rdf, because they could just as easily  
> link to
> a html webpage, jpeg imaged etc.  Even checking the mime types, one  
> can
> only tell that the pages shown are XML.
>
> I can see that it would be helpful to have the capability of opening
> arbitrary RDF in the LSID Browser, and I'd be happy to hear feature
> suggestions as to how that should be done.  It would be pretty  
> simple to
> have a right click menu 'open link in RDF browser'.   It would be
> possible to have script run automatically each time you click a  
> link to
> fetch the data, check to see if Firefox could parse it as RDF and then
> toss it in the LSID Browser if it did, but that could add quite a  
> bit of
> overhead to browsing.
>
>> One suggestion (thanks to Ricardo Pereira) would be to have a tool
>> tips like approach to these things. One probably doesn't want to
>> display the whole RDF Schema vocabulary just because some one clicks
>> on seeAlso link. It would be better to display the documentation of
>> that item in the vocabulary.
>
> That would definitely be a great feature, and if anyone over there is
> interested in writing it up I'll do my best to get it folded into the
> project.  Again, one would have to somehow determine that link is  
> to XML
> RDF, and that it was a part of a schema.  http links could be just as
> easily linking to terabytes of binary data, and you wouldn't want to
> start a large number of such downloads just by mousing over some URLs!
>
> cheers,
>
> Alyssa
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Lsid-developer mailing list
> Lsi...@li...
> https://lists.sourceforge.net/lists/listinfo/lsid-developer

I will be out of the office starting  12/29/2006 and will not return until
01/14/2007.

If it is urgent, please contact Rita Lamenza (617) 693-3830.

Hello Roger,

> It seems clear to me that any LSID client software has to understand
> URL type URIs and attempt to render them. 

The problem with this is these http URLs are not retrieved via the
lsidres: protocol handler, they're handled by Firefox's native http
protocol handler which unfortunately does not display RDF in a reader
friendly manner.  It doesn't really make sense for the firefox plugin to
assume all http URLs are rdf, because they could just as easily link to
a html webpage, jpeg imaged etc.  Even checking the mime types, one can
only tell that the pages shown are XML.  

I can see that it would be helpful to have the capability of opening
arbitrary RDF in the LSID Browser, and I'd be happy to hear feature
suggestions as to how that should be done.  It would be pretty simple to
have a right click menu 'open link in RDF browser'.   It would be
possible to have script run automatically each time you click a link to
fetch the data, check to see if Firefox could parse it as RDF and then
toss it in the LSID Browser if it did, but that could add quite a bit of
overhead to browsing.  

> One suggestion (thanks to Ricardo Pereira) would be to have a tool
> tips like approach to these things. One probably doesn't want to
> display the whole RDF Schema vocabulary just because some one clicks
> on seeAlso link. It would be better to display the documentation of
> that item in the vocabulary.

That would definitely be a great feature, and if anyone over there is
interested in writing it up I'll do my best to get it folded into the
project.  Again, one would have to somehow determine that link is to XML
RDF, and that it was a part of a schema.  http links could be just as
easily linking to terabytes of binary data, and you wouldn't want to
start a large number of such downloads just by mousing over some URLs!

cheers,

Alyssa

Hi All,

We are working on the metadata vocabularies for use with LSIDs issued  
in the TDWG biodiversity community and I have a question regarding  
the Firefox plugin that might have wider implications.

If you use the Firefox plugin to open this example LSID from  
IndexFungorum (thanks to Paul Kirk and Kevin Richards)

lsidres:urn:lsid:indexfungorum.org:names:213660

Then you get nicely rendered metadata but if you click on any of the  
property names you get very badly rendered RDF (unless you have some  
other magic plugin) because the vocabulary used is based on plain old  
URL type URIs.

The same happens with some property values (click on ICBN) because  
they are also resources identified by URIs - even though they return  
RDF.

Some might say that in an LSID world the entities in the vocabulary  
should be identified by LSIDs. So if we look at a pubmed example of  
this from the Biopathways site:

lsidres:urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:pubmed:12441807

Some of the properties are defined using LSIDs and some use RDF. So  
for the naive user (me?) it appears completely random as to what will  
happen. Even though the metadata is essentially the same.

It seems clear to me that any LSID client software has to understand  
URL type URIs and attempt to render them. We are always going to use  
non-LSID type vocabularies in our metadata. In fact the more we use  
other peoples vocabularies the better.

So my question is: What should the behavior of an LSID browser be?

If it renders the vocabulary terms identified by other URI types then  
it is becoming a full blown semantic web browser - nice but not  
trivial to implement.

One suggestion (thanks to Ricardo Pereira) would be to have a tool  
tips like approach to these things. One probably doesn't want to  
display the whole RDF Schema vocabulary just because some one clicks  
on seeAlso link. It would be better to display the documentation of  
that item in the vocabulary.

What do you think?

All the best,

Roger

****************************************
   Roger Hyam <ro...@td...>
   Biodiversity Information Standards
****************************************

I haven't used LSIDAssigner myself, but there appears to be an example 
use of it in LSIDTestClient in the lsid-client jar.

I suspect the endpoint to use in the SOAP location is specified in 
web.xml as the servlet-mapping to the AssigningServlet, .../assigning by 
default.  The port should just be whatever Tomcat is running on, so you 
would create the LSIDStandardPort like so:

new SOAPLocation("http://mydomain.org:8080/assigning");

-Eric

Allyson Lister wrote:
> Hi all,
> 
> Sorry to ask about something that I should probably know about, but I am 
> a newcomer to actually *using* web services :)
> 
> I'm using the lsid toolkit provided by Benjamin and others, and I wanted 
> to try using the LSIDAssigner.java code just to see how a hypothetical 
> lsid assigner would work, but unfortunately I have no idea how to 
> construct the LSIDStandardPort port that it requires in its constructor. 
> I have the default authority and authority/assigner running in my 
> tomcat, but I have not used SOAP or web services, and I don't know where 
> to get the information needed to fill the port details - is there an 
> example use of LSIDAssigner somewhere in the toolkit? Also, will the 
> SOAP port be different from the port where tomcat is sitting? I'm 
> guessing yes...?
> 
> Again, apologies if this is blindingly obvious to everyone, but a push 
> in the right direction would be most helpful!
> 
> Regards,
> Allyson
> 
> -- 
> Allyson Lister
> Research Associate
> Centre for Integrated Systems Biology for Ageing and Nutrition
> Newcastle University
> http://www.cisban.ac.uk
> School of Computing Science
> Newcastle University
> Newcastle upon Tyne, NE1 7RU
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Lsid-developer mailing list
> Lsi...@li...
> https://lists.sourceforge.net/lists/listinfo/lsid-developer

2003	Jan	Feb	Mar (9)	Apr (4)	May (4)	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2004	Jan	Feb (3)	Mar (11)	Apr (8)	May (9)	Jun (21)	Jul (2)	Aug (2)	Sep	Oct (24)	Nov (2)	Dec (3)
2005	Jan	Feb	Mar (5)	Apr (1)	May	Jun	Jul	Aug (3)	Sep (2)	Oct (9)	Nov (1)	Dec
2006	Jan (1)	Feb (27)	Mar (4)	Apr (3)	May (3)	Jun (4)	Jul	Aug (1)	Sep (4)	Oct (3)	Nov (18)	Dec (2)
2007	Jan (12)	Feb	Mar (3)	Apr	May (2)	Jun (4)	Jul (1)	Aug	Sep	Oct	Nov	Dec
2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2012	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec

lsid-developer Mailing List for LSID (Life Science Identifier)

lsid-developer — Developer list