In the context of the URI Best Practices discussion, I would be interested
in hearing everyone's opinion on httpRange-14. Is this something acceptable
as is? Should it be modified/extended for Life Sciences? Section 6 of:
http://www.ibiblio.org/hhalpin/irw2006/hhalpin.pdf
has a nice summary of t
On Jul 24, 2006, at 9:55 AM, Sean Martin wrote:
Hi Alan,
[EMAIL PROTECTED] wrote on 07/23/2006 11:51:35 PM:
Are you suggesting that programs parse URIs to see if they contain
the ASCII string "static"? If so, how would ones program know the
difference from any of these links?[1] I can s
--Alan
> XW> Should a LSID resolver decide not to resolve a
> particular LSID, wouldn't it
> XW> be the same effect as a broken link?
>
> Not really for a number of reasons. The first is that
> you may well already have it stored somewhere accessible if
> it has ev
blic/public-semweb-lifesci/2006Jul/0074.html
Kindest regards, Sean
Henry Story <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
07/24/2006 06:45 AM
To
Sean Martin/Cambridge/[EMAIL PROTECTED]
cc
public-semweb-lifesci@w3.org
Subject
Re: BioRDF: URI Best Practices
I too would
Hi Alan,
[EMAIL PROTECTED] wrote on 07/23/2006
11:51:35 PM:
>
> On Jul 21, 2006, at 2:53 PM, Sean Martin wrote:
>
> > XW> Should a LSID resolver decide not
to resolve a particular LSID,
> > wouldn't it
> > XW> be the same effect as a broken link?
> >
> > Not really for a number of reasons.
> It seems to me that content negotiation is a pre-semantic web way
of
> handling a bit of semantics. Why not adopt a uniform way of handling
> these things? You could certainly support content negotiation
> discovered information by translating it to to the more expressive
> rdf/owl.
>
I c
-- Alan
> Also, mime types tell you the format of the resource, but
> not the type of content. So compare a definition and a policy
> statement metadata for a uri. Both might be text/rdf+xml, no?
I am not sure what is your point here? What do you mean "compare a
definition and a policy for a
-- Alan,
> You are right in the sense that if I receive a naked URI in
> the email I'll have to dereference it to learn something
> about it. OTOH, this is not the case I am thinking about. I
> am more concerned with URIs that I find in a SW context -
> namely part of a graph - a packet of SW
Forgive me if I'm missing the point or just stating the obvious, but the "Generate OWLDoc" feature in Protégé - at least for Protégé-OWL files, works very nicely. It's not the dynamically-generated view I'd really want ultimately, but it works great for a snapshot of an OWL-based ontology.For an e
On 24 Jul 2006, at 13:16, [EMAIL PROTECTED] wrote:
I too would be interested in understanding why people in the life
sciences don't use URLs, because I think the advantage of using
them is absolutely huge. Being able to "GET my meaning" [1] makes
the Semantic web so easy to explain, so simple t
> I too would be interested in understanding why people in the life
> sciences don't use URLs, because I think the advantage of using
> them is absolutely huge. Being able to "GET my meaning" [1] makes
> the Semantic web so easy to explain, so simple to read, so
> beautiful all in all that one rea
I too would be interested in understanding why people in the life
sciences don't use URLs, because I think the advantage of using them
is absolutely huge. Being able to "GET my meaning" [1] makes the
Semantic web so easy to explain, so simple to read, so beautiful all
in all that one real
On Jul 21, 2006, at 11:38 AM, Xiaoshu Wang wrote:
notwithstanding, I'd rather know that I am dealing with a
non-information resource *before* I touch the network.
I am very puzzled, how can you tell a IR or non-IR given any URI,
unless you
have the knowledge about all URI before hand? Do
On Jul 21, 2006, at 10:59 AM, Chimezie Ogbuji wrote:
As Xiaoshu pointed out, content negotiation (specific accept headers
dispatched to a URL) give you *most* of this functionality purely at
the transport level - assuming there are appropriate mime types for
the representation you have in mi
On Jul 21, 2006, at 2:53 PM, Sean Martin wrote:
XW> Should a LSID resolver decide not to resolve a particular LSID, wouldn't it
XW> be the same effect as a broken link?
Not really for a number of reasons. The first is that you may well already have it stored somewhere accessible if it has ev
This URL vs. LSID discussion is reminding me of a poem that I think I
will share with you all, since it is a gorgeous warm and sunny Friday
afternoon here in Vancouver and I'm just in the mood to be cheeky ;-)
Enjoy! Have a great weekend everyone!
The Calf Path
-
One day, through
> SM> as names for things that have a digital
existence. The issues
> SM> of broken links is a difficult one because
once the primary
> SM> source at a particular location disappears
you have nothing
> SM> left to go on to find a copy of the thing
named besides what
> SM> you can find in the W
On Fri, 21 Jul 2006, Xiaoshu Wang wrote:
To discribe if an IR has multiple representations is different from to
describe if it is IR or non-IR. Let's not mess this two up. The former is
useful. For instance, if a data is available in XHTML, WML, word, PDF, etc.
Then we can further use the
--Sean,
> as names for things that have a digital existence. The issues
> of broken links is a difficult one because once the primary
> source at a particular location disappears you have nothing
> left to go on to find a copy of the thing named besides what
> you can find in the WayBack mach
--Alan,
> notwithstanding, I'd rather know that I am dealing with a
> non-information resource *before* I touch the network.
I am very puzzled, how can you tell a IR or non-IR given any URI, unless you
have the knowledge about all URI before hand? Don't you have to
de-reference the URI at fir
Title: Message
Hi
All,
(from
Sean)
"The issues of broken links is a difficult one
because once the primary source at a particular location disappears you have
nothing left to go on to find a copy of the thing named besides what you can
find in the WayBack machine or perhaps a Google
ca
Hi Alan,
> So my proposal suggests a class that defines
ways of transforming the
> URI you find in a SW document into URLs that get specific types of
> information. The fact that a transform to URL is provided means you
get
> the transport (because it is part of the transformed URL). Differ
On Fri, 21 Jul 2006, Alan Ruttenberg wrote:
Nice idea. I've added a similar proposal to the same wiki page[1].
Basically, I would argue that there are three aspects to dereferencing, with
the problem being that there is no one thing that you always want
dereferencing to get you.
1. T
Nice idea. I've added a similar proposal to the same wiki page[1].
Basically, I would argue that there are three aspects to
dereferencing, with the problem being that there is no one thing that
you always want dereferencing to get you.
1. The kind of information you want to get by derefe
On 7/20/06, Matthias Samwald <[EMAIL PROTECTED]> wrote:
On the page
http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Use_Cases
I have written that an "ontology of resolvable resources" would be practical in
some cases.
I have created such a small ontology, it can be dow
Matthias,
> The motivation for my proposal was that I think it is better
> to know which URIs are supposed to be resolvable before we
> are actually trying a HTTP GET or try to resolve something
> with the LSID system. In large datasets we have plenty of
> URIs -- if every agent would try to
On Thu, 20 Jul 2006 11:48:56 -0400, Xiaoshu Wang wrote:
> What you said is not correct that "When RDF was invented it was
> mostly intended to be used with URLs of the second group", Tim
> Bernerds-Lee has long envisioned that URI is for everything.
Agreed, however I have observed that the emphas
Matthias,
> On the page
> http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_
> Practices/Use_Cases
> I have written that an "ontology of resolvable resources"
> would be practical in some cases.
If you read "the Architecture of World Wide Web
http://www.w3.org/TR/webarch/";, you wou
On the page
http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Use_Cases
I have written that an "ontology of resolvable resources" would be practical in
some cases.
I have created such a small ontology, it can be downloaded / imported from
http://neuroscientific.net/ont/reso
hi Susie,
Is there any chance that we can have
a section that details the pro's and con's of URL's as URIs in a Life Sciences
setting. It is my understanding that the LSID URN was created in
response to certain short comings of URLs as names - but may
well not have over come them and so the var
30 matches
Mail list logo
