I've posted a newer version that may make some things clearer, and
undoubtedly will make other things less clear. Thanks to everyone for
raising questions - every confusion surfaced helps to improve the end
result.
http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Recommen
The GET problem seems pressing and almost tractable,
and we have a lot of experience with it. Finding SPARQL endpoints is
novel, everyone's using ad hoc solutions, and the need for shared
solutions is not so pressing.
I am confused about the use cases that you are attempting to address.
On Fri, 9 Feb 2007 Booth, David (HP Software - Boston) wrote:
> I'm curious why you are treating this case so differently from the
> case of finding information about an information resource. I
> assume it is because with information resources you are only
> interested in information from that in
> From: Jonathan Rees [mailto:[EMAIL PROTECTED]
>
> Doing HTTP operations on an information resource, while abstractly
> similar to answering SPARQL queries relating to it (in either case you
> are learning something), seems to have a different feel given present
> technology. The protocol used
Doing HTTP operations on an information resource, while abstractly
similar to answering SPARQL queries relating to it (in either case you
are learning something), seems to have a different feel given present
technology. The protocol used is HTTP and the stuff you get has types
(e.g. image, PDF) t
> From: [EMAIL PROTECTED]
>
> >> In your view, how would one find
> >> information (or represent the information needed to find
> >> information) about a non-informationresource
>
> I think parallel querying of Sparql endpoints could be an
> interesting solution. . . . .
I'm curious why you ar
>> In your view, how would one find
>> information (or represent the information needed to find
>> information) about a non-informationresource
I think parallel querying of Sparql endpoints could be an interesting solution.
To get additional information about a non-information resource (say, a
I haven't been able to follow this discussion entirely, so please
forgive me if I missed something that should have been evident. In
general I like the idea of using an ontology to express URI resolution
information, but I am also partial to Xiaoshu's pleas for simplicity.
To my mind, the ideal w
On Tue, 6 Feb 2007 14:04:20 -0500, Jonathan Rees wrote:> This leads me to think that the main relation we are looking for is> one between an information resource (which may have multiple URI's)> and a *string* that is a URL that will help us to get its> representation.
Exactly. It would be impor
This leads me to think that the main relation we are looking for is
one between an information resource (which may have multiple URI's)
and a *string* that is a URL that will help us to get its
representation. Maybe this is obvious.
The www notion of 'resource' includes things that have differen
-semweb-lifesci@w3.org
Cc: public-semweb-lifesci@w3.org
Subject: Re: [BioRDF] URI Resolution
Eric Neumann wrote:
Since much of what is being discussed here is about a "practical
time to turn-around" for resolution, this is a quantitative
criterion that can be measured.
Why not set
ci@w3.org
Subject: Re: [BioRDF] URI Resolution
Eric Neumann wrote:
> Since much of what is being discussed here is about a "practical time to
> turn-around" for resolution, this is a quantitative criterion that can be
> measured.
>
> Why not set up a small demonstration for
Eric Neumann wrote:
Since much of what is being discussed here is about a "practical time to
turn-around" for resolution, this is a quantitative criterion that can be measured.
Why not set up a small demonstration for handling some class of URI's (e.g., list of
genes), that have getMethods, a
L PROTECTED] on behalf of Alan Ruttenberg
Sent: Mon 2/5/2007 3:23 PM
To: Xiaoshu Wang
Cc: public-semweb-lifesci@w3.org
Subject: Re: [BioRDF] URI Resolution
On Feb 5, 2007, at 3:02 PM, Xiaoshu Wang wrote:
> Alan Ruttenberg wrote:
>> On Feb 5, 2007, at 1:49 PM, Xiaoshu Wang wrote:
&
> The same XML (or HTML) document with different character encoding can
> end up in different byte-streams. Hence, if there are two identical
> ontologies backed up at different locations but served with different
> character encoding, would you consider they "lied" if they say that they
> a
However you define identity, the point remains the same. If you say
that two URIs denote the same thing, then retrieve them and find that
your chosen definition of identity doesn't say they are the same, then
you have "lied" in making the sameAs statement. Failing that you may
use whatever t
On Feb 5, 2007, at 4:00 PM, Xiaoshu Wang wrote:
The lie would be if you did a geturl on http://purl.example.com/
#aColor and retrieved the bytes "010203" and you did a get on
http://foo.com/#aColor and retrieved the bytes "030201". Remember,
you said they were sameAs, and same information r
It's been interesting following your positions on this issue, and timely for
us as we are faced with a decision as a start-up on whether to embrace
standards, pursue our own architecture, or some combination thereof. My
personal preference has always leaned towards interoperability, but
conse
The lie would be if you did a geturl on
http://purl.example.com/#aColor and retrieved the bytes "010203" and
you did a get on http://foo.com/#aColor and retrieved the bytes
"030201". Remember, you said they were sameAs, and same information
resources have the same bytes. That was the point.
On Feb 5, 2007, at 3:02 PM, Xiaoshu Wang wrote:
Alan Ruttenberg wrote:
On Feb 5, 2007, at 1:49 PM, Xiaoshu Wang wrote:
So, an email client need to run Javascript or something like that.
Is that a problem? There are free implementations of javascript.
Most modern mail clients have one anyways
> So, each the entire RDF document will be tripled? I thought David and
> Mathias were saying that shouldn't happen if you describe the semantics
> of string that forms the URI. But please note the difference, one is an
> Ontology describe the meanings of a strings, which in turn describes th
Alan Ruttenberg wrote:
On Feb 5, 2007, at 1:49 PM, Xiaoshu Wang wrote:
Indeed. What I spelled out could be implemented in javascript and
the javascript put in the rdf directly. Then it would be simply a
matter of saying javascript "eval". Think ahead!
So, an email client need to run Javascrip
On Feb 5, 2007, at 2:05 PM, Xiaoshu Wang wrote:
Another problem is that if I want to say that
http://purl.example.com/#purl owl:sameAs http://bar.com/#bar .
However, http://purl.example.com/#purl is a well maintained
persistent URI. With your proposed approach, does that mean that
http://
On Feb 5, 2007, at 1:49 PM, Xiaoshu Wang wrote:
Indeed. What I spelled out could be implemented in javascript and
the javascript put in the rdf directly. Then it would be simply a
matter of saying javascript "eval". Think ahead!
So, an email client need to run Javascript or something like th
I am not assuming you are retrieving each uri one by one. Chunks of
things come in files. The ontology as a whole is in one file. You
are correct that one always has a bootstrap issue. However I
anticipate that the core of the URI resolution ontology, given its
importance, would be available
Indeed. What I spelled out could be implemented in javascript and the
javascript put in the rdf directly. Then it would be simply a matter
of saying javascript "eval". Think ahead!
So, an email client need to run Javascript or something like that.
Isn't this proposing some uniform treatments
On Feb 5, 2007, at 12:42 PM, Xiaoshu Wang wrote:
So, instead of saying "hey, here is the URI". You would say "Oh,
here is the URI and then go here and there, and follow these
protocols, you can then know something about this resource." Do you
honestly consider this an elegant solution?
I
I (or my software) would send you a small package of triples.
Effectively:
1. The location of the ontology that includes VitaminSourceDemoThing
2. The resource of interest: http://www.example.org/NM_013987_XML
You would know (because we have agreed on the outline of how we
resolve URIs) to f
Hi Xiaoshu,
On Feb 5, 2007, at 10:08 AM, Xiaoshu Wang wrote:
Alan
Please review slides 31-34 in [1] for a precise example of the
technique I am referring to. There is a link to working code that
implements the example within lsw [2]
O.K. Let us work on the provided example. Assume that you
Alan
Please review slides 31-34 in [1] for a precise example of the
technique I am referring to. There is a link to working code that
implements the example within lsw [2]
O.K. Let us work on the provided example. Assume that you found a
VitaminSourceDemoThing that might interest me. How are
On Feb 4, 2007, at 3:59 PM, Xiaoshu Wang wrote:
I am not sure how owl:hasValue can be used here? The owl:hasValue
is intended for a resource, but not the string that IDed the
resource right? For instance, if there is an ontology says the
rabbit:favoriteFood is ex:carrot. It implies every
Remember that we are using OWL, which has inheritence. Using an owl
hasValue restriction we can have a set of triples specified once, but
with the reasoner have be as if each instance has those triples[1].
BTW, I will anticipate the complaint about the OWL reasoner's
heaviness. Although we a
On Feb 2, 2007, at 10:24 AM, Xiaoshu Wang wrote:
I am very doubtful about the practicality of such an ontology.
First, consider the size. RDF is all about URI. If an RDF
document has n statement, there will be 3n URIs. If k statements
are needed to describe the resolution of one URI, th
On Feb 3, 2007, at 2:22 PM, Xiaoshu Wang wrote:
Also, I found this sentence in the example of the problem statement
"...How to make the user's application work without having to
rewrite the RDF? "
You still need to rewrite the RDF even if you have a resolution
ontology, am I right?
No, you
Matthias Samwald wrote:
> - If the server replies 303 See Other, follow the link in the
> response to get information about resource. [obscure hack but worth
> a try]
> (see http://www.w3.org/2001/tag/issues.html#httpRange-14)
I guess we should find a diplomatic formulation for that.
> - If the server replies 303 See Other, follow the link in the
> response to get information about resource. [obscure hack but worth
> a try]
> (see http://www.w3.org/2001/tag/issues.html#httpRange-14)
I guess we should find a diplomatic formulation for that.
> - Disadvantage: you need an O
- Mint URL's whose hostname specifies a long-lived server that will
maintain the resource at the given URL in perpetuity.
(Publishers,
libraries, and universities are in good positions to do this.)
[good as for as it goes, but user may not be in control, or may
find quality
> From: Xiaoshu Wang
>
> > From: David Booth
> > . . .
> > My overall comment: Yes! I believe a URI resolution ontology could
> > significantly help address these problems, while still
> > permitting URIs
> > to be based on the http scheme, thus facilitating bootstrapping and
> > minimizing ba
My overall comment: Yes! I believe a URI resolution ontology could
significantly help address these problems, while still permitting URIs
to be based on the http scheme, thus facilitating bootstrapping and
minimizing barriers to adoption.
I am very doubtful about the practicality of such an
Re: http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Documents?actio
n=AttachFile&do=get&target=getting-information.txt
My overall comment: Yes! I believe a URI resolution ontology could
significantly help address these problems, while still permitting URIs
to be based on the http scheme, thus fac
Tim's slides and other documents for his take on URI's, e.g.
http://dig.csail.mit.edu/2007/Talks/0108-swuri-tbl/
Acknowledgments: Chris Hanson, Tim Berners-Lee, Dan Connolly
]]
David Booth, Ph.D.
HP Software
[EMAIL PROTECTED]
Phone: +1 617 629 8881
> -Original Message-
Sorry, I should have changed the subject line. Please reply to this
message, not the previous one, so that the thread gets properly
threaded.
On 2/1/07, Jonathan Rees <[EMAIL PROTECTED]> wrote:
As promised, here's a draft of a document about what we've been
calling the "URI resolution" problem,
42 matches
Mail list logo
