Matthias Samwald wrote:
Yes, with most current web-browsers (those that are not aware of the
embedded RDF), this could require users to make two clicks instead of
one.
I do have the Firefox Operator plug-in installed, but I don't quite
understand how this would allow me to skip the intermediar
Eric Jain wrote:
> > http://whatizit.neurocommons.org/template_303.htm
>
> That's nice, but when I show such pages to our biologists, they still think
> it's some kind of error page, with all the gobbledygook about "commitment",
> "representation" and "URI"...
Certainly there is still a lot o
Eric Jain wrote:
[EMAIL PROTECTED] wrote:
I would also prefer that the file extensions are preserved, but is it
really such a big deal? Requiring the redirect service to fetch the ID
from the middle of the URI definitely makes things more complicated, and
it is mostly a matter of taste.
Th
[EMAIL PROTECTED] wrote:
I would also prefer that the file extensions are preserved, but is it
really such a big deal? Requiring the redirect service to fetch the ID
from the middle of the URI definitely makes things more complicated, and
it is mostly a matter of taste.
There are good reasons
EricJ wrote:
>Here are my own reasons for not using
> them in UniProt so far (despite the fact that I recognize that there is a
> big need for someone to provide URIs for databases without usable URIs).
>
> 1. Given a PURL with "uniprot" and "P00750", it can't be rewritten to
> http://beta.unip
Jonathan Rees wrote:
Thanks. I guess I thought it was obvious, but nothing seems to be in
this territory. I added
7. likelihood of adoption by uncommitted HCLS members [added 8/25]
8. ease of adoption [added 8/25]
Some specific questions to consider:
1. What effort is required for a data
Thanks. I guess I thought it was obvious, but nothing seems to be in
this territory. I added
7. likelihood of adoption by uncommitted HCLS members [added 8/25]
8. ease of adoption [added 8/25]
About the http://purl.org/commons/ URIs, I think it would be wrong to
interpret their non-adop
