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, in order to deal with
html mail. Many phones have one now, or will soon. Any barrier to
this will be overcome by technology advances in the very short
term, it seems to me.
Sure, everything is doable if we agree upon doing certain things.
Just as our discussion on LSID, there is nothing wrong with its
design and intension. It is just too expensive and too time
consuming to make everyone accept that. Unless it is a globaly
accepted practice, it won't solve the URI resolution problem, don't
you agree?
We will need to agree on something.
Why I think an URI Resolution Ontology is not appropriate. Let's
just consider the speed. The URI resolution problem is just a
redirection or URI-substitute. A simple lookup would be enough.
Using reasoning is an overkill of the problem at least.
Well, we will have to disagree about this.
You would add
Class(http://bar.com/#bar_1 Partial Restriction(getMethod hasValue
(transformingURIRetrievalForFoo))
Individual(transformingURIRetrievalForFoo
type(transformingURIRetrieval)
value(matchingPattern "http://foo.com/(.*)")
value(replacementPattern "http://blarg.com/$1";))
This is my point. The semantics you wanted is the
"matchingPattern" of the string. Therefore, you are describing the
meanings of name, but not the meanings of the resource that the
name is point to.
There is no problem here. There is a single property getMethod. We
have described what it does with what. It doesn't interfere with the
other statements I make about the resource.
As your reply to the next question already talking about multiple
getMethods and using heuristics, don't you think the solution is
getting messier and messier?
Have you ever read the code for a web server? Everything is messy to
some extent. I find this less messy and more importantly I, and
anyone else has a chance of understanding it using "view source",
then tweaking it to serve their purpose. There is no magic behind the
scenes like there is with content negotiation, for instance.
The assumption is that there may be multiple getMethods, and that
each will return the same resource if you ask for it (otherwise
the sameAs is a lie). Therefore a robust client will try all the
getMethods for a thing and all things it is same as, and stop when
the first one succeeds. If the getMethod for #bar is applied to
#purl the worse thing that can happen is that it will fail and the
original getMethod for #purl will eventually be tried and succeed.
Smart resolvers might use heuristics to choose which methods to
try first, but this won't change the outcome.
I don't understand the "lie" part. Consider the following
example. Assuming two researchers, one works on a dog. The other
studies a cat. The dog guys make a note saying [snip]
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. Since this is the case, it doesn't matter if you
retrieve one or the other of them, which was justification for saying
that you may try any getMethod and stop after the first one that
retrieves something.
I'll point out once again the confusion between
NotAnInformationResource and InformationResource. Colors are not
information resources.
-Alan
