Re: BioRDF Telcon

The CommonNaming page talks about the issue of server load; client
load is also a problem, and client-side redirection and caching are,
as you observe, the answer. Alan Ruttenberg presented an RDF-based
rule mechanism for this in Amsterdam, and it surprises me a bit that
you've made no reference to it (must be due either to lack of
publicity or because the available materials (slides?) are hard to
understand on their own).

I really think we should put together a set of requirements and
desiderata for proposed URI solutions, especially since we seem to
have at least 4 proposals (LSID, Banff demo, yours / Bio2RDF, BioGUID)
on the table just in this one sub-area (URI's for public database
records). This requirements set should give us an objective way to
compare and merge proposed solutions. Adopting sane engineering
process should help us focus discussion, make rational decisions, and
secure adoption. I plan to put together my own requirements set; a
rough start is already in the ESW wiki. But I would appreciate it if
you and others would separate requirements from solutions for
yourselves, and record the results somewhere (ESW would be the right
place except for the speed problem, ugh). Otherwise, I will have to
reverse engineer requirements from email messages myself, and I will
get fewer other things done.

For example, use of purl.org is no one's requirement; supporting http
get and durable access are requirements (for some people).

And by the way, I was asking for your comments on the work plan, not
on any particular proposal. Do you support the work plan, and will you
participate in it? It's here:
http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Work_Plan
I really don't want to go to a lot of trouble to compile a document
only to get a mountain of objections at the last minute.

Jonathan

On 6/19/07, Marc-Alexandre Nolin <lotus@ieee.org> wrote:
> Hi,
>
> In fact, it is not a complete new wiki on this discussions. In this
> conversation, Kei Cheung give a URL about the Banff Manifesto. The
> problem is, this document is not up to date anymore and since I'm not
> aware of a functionalities for anybody to add comments on a Google
> documents, we transfert it into a wiki. My email was a correction URL
> about the URL given by Kei previously.
>
> I can put a copy of it on the W3C wiki if you want, I don't see any
> problem with this. I put it in my wiki because it is revelant to the
> documentation of the Bio2RDF.org system wich use those rules to work
> (We had to take decision about how we will normalize the URI we had or
> else we would not have a working system by now). This wiki is the
> documentation and the "how to use" the Bio2RDF.org system. Some people
> at the HCLS workshop ask for it and it's why we are providing it (also
> for us, because it help structure our work).
>
> As for the comments you ask of me on the already existing document
> about URI that you provide in you email:
> I was at the informal discussion on URI in Banff animated by Eric N.
> I'm all for a common decision about how to write URIs. In this
> discussion (and also in the link you provide), I've seen that the
> proposal to use Purl to get the caracteristics about how to write a
> specific URI for a specific namespaces might be interesting, except
> for the load we may put on the Purl server. In the end, the proposal
> in the manifesto isn't really far from this, except that it is a
> distributed way of doing this. Just a set of simple rule to apply and
> the URI will connect. Purl could distributed the set of rule to write
> every URI for specific namespaces. This way, a developer would go
> there, read the rules, implement it in his system and  now his data
> can connect with other program develop with those rules. The load on
> Purl will be minimal, only developer and data manager will go there to
> know the set of rules for URI for the data, not the millions of URI
> request generated by every query on the life sciences space.
> I'm for an HTTP resolvable URI, any browser or for that mather any
> perl, ruby, Java script can resolve a HTTP link. I'm not convince yet
> about the usefulness of pure LSID, it became useful if it is a use in
> a URL like http://purl.org/urn:lsid:uniprot.org:uniprot:p26838 because
> automatically I don't have to be stuck with a plugins in a specific
> browser or using some LSID resolver on a server somewhere
> Also, and not completely related to the current discussion, I've read
> about going to concept in one of the pages you've link in your
> precedent email. I also think we should go there for URI. As much has
> we would like to call uniprot:p19367 a concept, it is still a database
> number from the database uniprot. The real concept would be
> protein:Hexokinase. This is what the searcher would be looking for.
> The concept would then link to any database talking about it. For an
> idea about this, look for Hexokinase in Wikipedia
> http://en.wikipedia.org/wiki/Hexokinase , see in the right panel every
> reference to other database talking about it, not just Uniprot. With
> dbpedia http://dbpedia.org rdfizing Wikipedia, this could be very
> useful.
>
> Sorry for the long reply, but you ask for comments :)
>
> Marc-Alexandre
>
> 2007/6/19, Jonathan Rees <jonathan.rees@gmail.com>:
> > I hate to see the number of wikis used for this purpose multiply.
> > There's already some discussion in the ESW wiki, e.g.
> > http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices
> > and http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Work_Plan,
> > and in the neurocommons wiki,
> > http://wiki.neurocommons.org/CommonNaming.
> >
> > Are you avoiding the ESW wiki because it's so slow? That was one of my
> > reasons for using the neurocommons wiki for this job; I've regularly
> > been seeing up to 60 seconds for basic operations such as 'edit' and
> > 'save'. Eric P is looking into this. If it can't be fixed, I think
> > we'll have to choose a different location.
> >
> > As for a "base of discussion", I think we already have too many of
> > those. The trick is to relate new writings to old ones, or to update
> > old ones to make them better, and that's what we need a wiki for.
> >
> > Before I comment on your "manifesto", may I ask if you have any
> > comments on the URI practices work plan for which I requested
> > feedback? Or is it your preference to set up a parallel effort?
> >
> > Jonathan
> >
> > On 6/19/07, Marc-Alexandre Nolin <lotus@ieee.org> wrote:
> > >
> > > Hi,
> > >
> > > About this Banff Manifesto, me and Francois Belleau wanted to give a
> > > base of discussion with this text. The purpose of it, is to give some
> > > simple rule where, when you followed them, URI will connect together
> > > without having the added work to rewrite every URI before using them.
> > >
> > > For everybody to be able to place comment on it, the last version is
> > > in a wiki at
> > > http://bio2rdf.org/JSPWiki/Wiki.jsp?page=BanffManifesto
> > >
> > > In this same wiki, we are currently making a follow up of the article
> > > we present in Banff and explaining every normalization and decision we
> > > took about URI for our system to work. We welcome every comments.
> > >
> > > Marc-Alexandre Nolin
> > >
> > > 2007/6/18, Kei Cheung <kei.cheung@yale.edu>:
> > > >
> > > > Hi Jonathan et al.,
> > > >
> > > > Eric may add to it, but I just want to describe briefly what I know. At
> > > > the Banff HCLS-DI Workshop
> > > > (http://neuroweb.med.yale.edu/hcls/Welcome.htm), a number of authors had
> > > > presented their work involving their own URI convention/format. As a
> > > > result, there was a proposal called "Banff Manifesto"
> > > > (http://docs.google.com/View?docid=ddm4nhwq_41cpz6kq). There was a
> > > > follow-up meeting at Banff right after the HCLS demo that Eric and
> > > > others might be able to tell people more about it (I wasn't at the
> > > > follow-up meeting).
> > > >
> > > > Best,
> > > >
> > > > -Kei
> > > >
> > > > Jonathan Rees wrote:
> > > > >
> > > > >
> > > > > On 6/11/07, *Eric Neumann* <eneumann@teranode.com
> > > > > <mailto:eneumann@teranode.com>> wrote:
> > > > >
> > > > >
> > > > >     +1 !
> > > > >
> > > > >     I've also added a reference to the Banff discussion on URI's. I
> > > > >     plan to put this also on the agenda for the next HCLSIG TC (June 21).
> > > > >
> > > > >     -Eric
> > > > >
> > > > >
> > > > >
> > > > > Thanks, but for the benefit of those of us who weren't at this
> > > > > dicussion in Banff, could you summarize what transpired, or  give a
> > > > > link to minutes?
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>

Received on Wednesday, 20 June 2007 13:14:46 UTC