Re: Comment on: Providing and discovering definitions of URIs

Seven months later, but getting to it... let me say, on-list this time, how much I appreciate your comments. They are unusually concrete and fair. I hope I can find the time and energy to address all of them.

Before I start, I thought I'd give some quick reactions. I agree with everything you say except where otherwise noted.

On Jun 26, 2011, at 10:09 AM, Dave Reynolds wrote:

> This is a personal response to [1].
> 
> First, thank you for the document and the hard work that must have gone
> into it. Attempting to capture all the details of the issue and all
> suggested responses to it is a useful step.
> 
> Unfortunately I don't feel the document, in its current state, achieves
> the level of clarity required to move this debate forward and suggest
> some rework.
> 
> Specifically:
> 
> (1) There should be one set of criteria by which all the proposed
> solutions are evaluated. Those criteria should be clearly stated and
> justified.

The document is a survey of possible discovery methods, some of which have been gleaned and generalized from proposals received, not an enumeration of particular proposals received. My theory is that a complete solution might consist of a combination of several different discovery methods, perhaps combined with other small-r recommendations.

I guess I could just come out and say that.

> Currently the document lists six success criteria in section 1.1,
> evaluates the proposals against a different (rather biased) list of 5
> criteria and uses still other criteria in the discussion of some of the
> solutions. 
> 
> I expand on this below [3].

> (2) Several of the specific proposals are hard to recognize or follow in
> the current write up. Specifically 4.3 confuses the punning proposal
> with an attempt to reconcile punning with criteria 6 in section 1.1 and
> doesn't really communicate the proposal itself [4]. Similarly I assume
> that 5.3 is supposed to capture Ian Davis' "Back to basics" proposal [2]
> but it is hard to recognize and again seems to mix up the proposal with
> various ways to mutate and reconcile it with some of the criteria.

I am now referencing Ian's other blog post "Is 303 really necessary" instead, hope that works for you.

> (3) The document fails to address the question of Information Resources.
> IMO part of the confusion that surrounds http-range-14 arises from lack
> of clarity over exactly what is and isn't an Information Resource and
> whether and how that notion should get reflected in RDF, Linked Data and
> the Semantic Web. The glossary definition given here ("Roughly speaking,
> something that is appropriate as the subject of metadata") does not
> reduce that confusion. The status of the associated IR document is
> unclear.

The associated IR document is my best attempt to answer this question and I doubt I can do much better. The answer is probably more subtle than most people would like but I have found no other, despite five years of study. The status of the associated IR document is the same as the status of the document you reviewed: an editor's draft.

In my latest document (the "UDDP" draft, or httpRange-14 resolution replacement, http://www.w3.org/2001/tag/doc/uddp/ ) - which is meant to be able to hop onto Rec track if the TAG thinks that advisable - I try to gloss the question, which as both Tim and I have stated before is not the right question to ask in the first place. For me, remember, the point is that some properties of the instances/representation are shared with those of the referent/IR, and beyond that it doesn't matter what an IR is - it's just something whose properties are properties that representations can have (speaking VERY informally here). That HR14a calls this out is, in my opinion, a mistake in the resolution, one I'm trying to fix through this amendment process.

Let me repeat, as the confusion also came up when I was talking to Harry recently. Ignore HR14a, we can change that. "What is an information resource" is the wrong question. The right question is "what properties do we want to ascribe to the referent of a GOFHTW URI" (GOFHTW = good-old-fashioned-hypertext-web). Figure that out first, then from that form your own idea of what the referent is (and of its types).

The IR document is separated out exactly because it is distracting and relatively unimportant - or should I say has low return on investment. Generally the more one says on the subject the less satisfied one becomes; but that is not to say there is no satisfaction in it.

So my question for you is whether something like the IR document would need to be on Rec track as well, if UDDP is. I don't think so - I want to publish it merely as a TAG note or finding and then cite it in UDDP non-normatively. It may be too early to talk about that question now; perhaps we can take it up later in the process. But I hope you will think about it.

> (4) Perhaps minor but please adopt a consistent style for description
> and attribution of proposals and criticisms. The mix of well referenced
> criticisms with highly personalized arguments of the level "Harry
> says ..." is jarring. Some proposals are attributed some not.
> 
> I suggest reworking to unify and clarify the solution criteria and to
> initially present the set of existing proposals straight and assess them
> on their own merits. The attempts to recast or rationalize the proposals
> (especially as included in 4.3 and 5.3) would be better in appendices or
> in a separate discussion document.
> 
> Hope this helps.

Absolutely! A lot.
> 
> Dave
> 
> [1] http://www.w3.org/2001/tag/awwsw/issue57/20110625/
> 
> [2] http://blog.iandavis.com/2010/12/06/back-to-basics/

> [3] More detailed comments on success criteria
> 
> The initial enumeration of success criteria is:
>  1. Simple
>  2. Easy to deploy on Web hosting services.
>  3. Easy to deploy using existing Web client stacks.
>  4. Efficient. 
>  5. Browser-friendly.
>  6. Compatible with Web architecture.
> 
> The description of (5) misses out the issue of errors caused by showing
> the wrong URI in browser address bars. Arguments about specs aside it is
> simply the case that all browsers show the result of the temporary
> redirection and I've lost count of the number of errors in linked data
> and examples which this has caused. Either make that part of the
> "browser friendly" category or put it in a separate category. It is
> mentioned in the discussion in 3.6.4 but not pulled out.
> 
> The explanation of (6) "A URI should have a single agreed meaning
> globally" at least needs clarification. It is already the case that in
> OWL 2 one URI denotes two things (see below) and even in plain RDF a
> resource can have independent "class nature" and "property nature".
> Technically in those cases the URI still denotes one thing but that
> "thing" has independent natures.
> 
> Criterion 6 also ties back to the need to confront the "what exactly is
> an IR then" issue.
> 
> The summary section uses the success criteria:
> 
> (a) webarch?  
> (b) robust?
> (c) easy to deploy?
> (d) min round trips
> (e) sound?
> 
> So we have a=6, c=2, d=4. Criteria 1, 3, 5 are omitted, b and e are
> introduced.
> 
> Of these introductions then (b) is bizarre. The definition of
> "robustness" is "Is the URI free of fragment identifiers?"! Why not just
> have as one of your criteria "uses 303 redirects" :) Seriously if
> robustness is a criterion then define it and assess each of the
> proposals against it, ideally with some evidence. Personally I've never
> seen a case of fragment IDs getting lost but frequently see "/doc" forms
> used instead of "/id" forms. Is that an aspect of robustness? Does my
> anecdotal non-evidence trump Harry's anecdotal non-evidence?

You have exposed my bias, which is the same as yours - the way I worded the deideratum was meant to satirize it. I'm glad you saw this. It was a bit rude, and I will attempt to civilize it out of respect to those who hold to it.

> Then in the various discussion sections we see other criteria being
> used:
> 
>  3.1, 3.2  URI denotation identifiable from the URI alone, 
>            no context book keeping required.
> 
>  3.4    This discussion seems to assume implicit criteria of:
>     Solution already be defined by an IETF standard
>     Solution must not use DNS
>  which can't possibly be what was intended.
> 
> Aside: while I don't think LSIDs are "the answer" this section either
> needs rewriting or replacing with words to the effect of "we aren't
> going to discuss this option seriously". 

That's my intent, but don't know yet how to justify it.

>  3.5.1   All representations must define the URI the same way
> 
>  3.5.4   REST compatible, "works" with PUT, POST and DELETE
> 
>  3.5.5   ??
> 
>  3.6.4   Bookmarkability (noted earlier)
> 
>  4.3     Must not reinterpret existing vocabularies (an aspect of 
>          soundness?)
> 
>  5.3     Must provide a way to reference the "information resource" 
> 
> Some of these are subject to debate (e.g. the last one), some need
> better specification, all need to be gathered into one consistent place
> if these are the way the options are to be judged.

This list is amazing, thanks for all the work you put into this.

I think *all* of the putative criteria are subject to debate. Will try to be more clear about that.

> [4] I would characterize the "punning" proposal(s) as:
> 
> "A URI doesn't not denote a single thing. It can denote both a document
> and some abstract concept. Each vocabulary term should make it clear
> which referent the term applies to. Some applications and publishers may
> not even care."

I see, maybe we should talk of determining or documenting the "meanings" of the URI instead of the "meaning" of the URI.

But channeling TimBL, if there is more than one meaning, then the identifier is no longer either "universal" or "uniform". Maybe we just accept that though, and come up with yet another word for the "U" to abbreviate.

As you probably know I consider documents to be at least as abstract as anything else. (Frege took up the question of whether there was anything that was not a concept, but I don't know how that came out.) I think the idea is rather that the URI can refer to a document in one context, and to something described by the document in a different context. (And maybe other things in still other contexts, as in the OWL case.)

I have found this idea exceedingly difficult to write about clearly. I think the version in the document is a 3rd or 4th rewrite. Guess I will have to try again.

It has always seemed to me that the punning idea runs afoul of RDF semantics, but perhaps there's an analysis that evades this somehow. Maybe compatibility with RDF semantics should be a success criterion, one that won't necessarily be met?

(BTW I try to stay away from "denote" since the word has precise meanings in mathematics, linguistics, and philosophy that I prefer not to conjure.)

Thanks again
Jonathan

> There is some precedent for this. In OWL 2 direct semantics then the
> same URI can denote both an individual and an owl:Class. For example
> if :c1 and :c2 are each both classes and individuals and you assert :c1
> owl:sameAs :c2 that does not imply that they are the same class (have
> the same class extent).
> 
> This works in OWL 2 because the semantics of the OWL terms are carefully
> defined to make it work. It is clear in the model theory when an axiom
> applies to the "class nature" of the URI and when it applies to the
> "individual nature". [Making that particular approach work unambiguously
> for the IR/nonIR distinction and for all vocabularies including ones
> that are already published and only informally described would be ...
> hard.]
> 
> The discussion in 4.3 is saying something slightly different, it is
> saying that the URI still denotes just one thing, the document, but we
> reinterpret vocabularies as sometimes referring to the document and
> sometimes being a chained predicate that refers to a "designated
> subject" of that document. That may be one way to reconcile the punning
> proposal with criteria 6 but it is not obviously the same proposal and
> makes for a complex write up.

Received on Friday, 20 January 2012 21:52:45 UTC