Re: Comments solicited: "Providing and discovering definitions of URIs"

On Wed, Aug 3, 2011 at 3:54 PM, Noah Mendelsohn <> wrote:
> Jonathan Rees wrote:
>> Other work and activities call, so I will set July 15 as the day by
>> which I'd like to get comments.
> Well, I certainly blew that.

No problem, I haven't gotten back to working on the document yet.

> The good news, is that overall I think this is terrific, which I presume is
> a comment you can handle late :-).
> I do have one quibble which is just about terminology, albeit rather
> fundamental terminology.  The rest of this email is just an
> elaboration/attempt-to-justify that quibble.
> Quoting from [1]
>> The question may appear to be limited to RDF and its derivatives, but
>> tothe extent that there is supposed to be a single meaning for each URI
>> common to RDF
> I confess I trip over the above, and indeed also to some extent with the
> reference in the title to ">Definitions< of URIs".
> I tend to take the narrow view of URI as being a string, known to obey
> certain syntactic constraints, and serving as the identifier for a resource
> in the Web.  From that narrow perspective, it seems wrong to say that the
> URI >has definitions< of the sort you are discussing (I.e. its definition
> might be a Web page, a dog, a number, etc.)

Nowhere in the document does it say or even imply that a definition
might be a dog or a number. It is quite clear, I think, that a
definition is a bit of writing, just as the definition of a word in a
dictionary is a bit of writing. Maybe this could be made clearer, and
that will straighten out your confusion? But I really don't see how
you could possibly read the paragraph "The nature of definitions ..."
or the following one and think a definition could be a dog.

> Now, I understand that there is a parallel to the fact that words in natural
> language have definitions, and those words are, in writing, connoted by
> strings of letters.  In that sense, the string of letters "house" has a
> definition as something 3 dimensional that you might live in, as opposed to
> just being the character string, and it's tempting to use that as a
> precedent for giving definitions to URIs.

The definition of "house" in a dictionary is a bunch of words, in the
way I'm using "definition". The definition of "house" is not three
dimensional, it's some text. Houses are three dimensional, but they
are not definitions.

Again, I don't see how you could come to say what you're saying - my
prose is failing to do what it's supposed to do, in a way I don't
understand. If we can track down the reason maybe I can prevent others
from making the same misreading.

> For me, the URI case is different because the specifications are so clear
> that the term URI is for the string itself.  It would be as if, in English,
> we defined the term "word" specifically to connote the string of characters.

I think I see what you're saying - e.g. that "record" the verb is a
different word from "record" the noun and so on. I think you're saying
that a dictionary will treat these as distinct words with the same
spelling, and that you get definitions of words from a dictionary, not
definitions of spellings. URIs are not like words, they are like
spellings of words.

I can see how the parallel isn't exact but I can't figure out how this
is of any consequence. How could one go wrong? Is it really incorrect
to say you might look up a word-spelling in a dictionary?  After all,
that's what you actually do, since you may not know, until after
you've consulted the dictionary, which of the co-spelled words is the
one you came across.

> I don't know if I'm explaining my concern clearly, but I'd be happier with
> something along the lines of "Discovering the referent of URIs", or
> "Discovering properties of the referents of URIs." I'm still tripping over
> the notion that the character string "" has a
> definition that we might wish to discover.

But discovering the referent, while it may be what Carol wants, is not
the business of this document. The goal is to discover a definition (a
piece of writing). Then Carol reads the definition, and figures out
what the URI's meaning is. Perhaps the definition will let Carol
figure out what she wants to consider the URI's "referent" to be, but
that's not usually necessary, and in any case that's outside the scope
of this report.

To repeat - the report is *not* about meaning. It's basically a
protocol spec that tells you how to get bits of writing (definitions)
whose purpose, according to mechanisms not specified in the report, is
to help others find meaning. How they do that is an orthogonal matter.

Maybe I've been staring at the prose for too long - I don't see how
you could possibly read it as saying what you seem to think it says.
It would be helpful if you could identify where you got off track, and
if you're on track now, to figure out how to keep other readers on

You are NOT talking about a terminological quibble here - this is
about the basic purpose and approach of the document. There *is* a
terminological problem, which is what to call that bit of writing (see
below), but you haven't called that out as an issue.

> Looking in a bit more detail at some of the examples:
> At the start of section 2.1, the example is "Alice wants to >refer to<  a
> particular earthquake. Alice "mints" a new URI (one that is not yet in use)
> with the purpose of using that URI to refer to the earthquake." I don't see
> anything being "defined" there. Does that not support the notion that what
> others need to discover is not the "definition" of the URI, but (information
> about) its referent?

This is an example explaining the context in which the protocol(s)
might be used. In some *implementations* of the scenario, there will
be definitions (bits of writing that are intended to help Alice's URI
to refer). The definition is a means to an end.

Doesn't the sentence after that one make the relation clear? I guess I
need to expand it?

> In section 3.3 you say "A recent example is RFC 5870 for URIs defined to
> name geographic locations." Isn't this a bit clumsier than saying that the
> URIs name geographic locations (or if you prefer, that they 'refer' to them
> or 'identify' them)?  Saying that they are "defined to name" them seems
> clumsy, and again leaves me feeling that talking about define/definition
> isn't working so well.

Perhaps "defined to name" is clumsy, but this sounds to me like a copy
edit, not a threat to "definition". How about:

   A recent example is RFC 5870, which defines "geo:"-scheme URIs to
refer to geographic locations.


   A recent example is RFC 5870, which serves as a generic definition
for all "geo:"-scheme URIs.

> Even if my concern has merit, I expect that the necessary changes would be
> non-structural, if perhaps widespread. Again, I find the document overall to
> be excellent, very useful, appropriately detailed, balanced. etc. Thank you!
> Noah
> [1]

The word "definition" (for text intended to bear on meaning; text that
might be discovered through some process) seems to be tripping up
several people, for several different reasons. Sometimes it's because
they haven't bothered to look to see how I use the term, and they
imagine I mean something by it that I don't. Or else maybe they do not
want to give me permission to use the word in the way I would like to.
I suspect there is not going to be *any* choice of terminology that
will make everyone happy. But I'm happy to consider alternatives. So
far I've heard these suggestions:

1. documentation (of or for a URI)  - I like this better, but it has
gotten as many complaints as "definition"

2. declaration  - this is a good attempt, but IMO the word is too
specific and formal.  and it is closely associated with, with which I disagree.

3. description - this doesn't work IMO because it is too specific (not
all meaning-promoting bits of text are descriptions)

Maybe there's some clever phrase we can make up around the
nose-following metaphor. Where do you end up, if you follow your nose?
An odor source?


Received on Monday, 8 August 2011 21:04:52 UTC