Re: Editor's Draft of ISSUE-57 URI Usage Primer

On Wed, Oct 10, 2012 at 12:47 PM, Jonathan A Rees <rees@mumble.net> wrote:
> On Wed, Oct 10, 2012 at 11:48 AM, Alan Ruttenberg
> <alanruttenberg@gmail.com> wrote:
>
>>> I like the concept of "landing page" as being a page which "describes" something else.
>>
>> Expect that this is an incorrect characterization. First, "landing
>> page" is a piece of language, not a concept.
>
> Are you saying you don't understand how the 'URIs in data' document is
> using the term "landing page", or that you disagree with the choice of
> term?

I disagree with how "landing page" was understood by John, and I blame
the document this and other likely misunderstandings. My position is
that if the document is associating  "landing page" with a different
set of things than would commonly be understood (as demonstrated in
this case by reference to wikipedia) then it should use the technology
we have to show what the current best practice would be for doing so.
It would be better if it both used this technology as well as find a
different set of words to identify the things it currently considers
of type landing page, a set of words that is less likely to be
confused by readers who, for instance, are only shown a quote from the
document.

> They are two different questions.  We need a word for where you
> "land" when you GET, and "landing page" was the best we could come up
> with.

That isn't how Jeni defines it. Her definition "A landing page is any
page which contains a description of something else."

A page that asks for user and password isn't describing something
else. It is making a request.

> Inevitably the choice will be a term of art, no matter what
> term is chosen. There have been many other attempts at terminology,
> and none has stuck as well as this one.

It hasn't stuck very well, apparently, as even two people in the TAG
(you and Jeni, as evidenced by your conflicting definitions) aren't in
sync. That should be evidence enough that you need to try harder.

> I guess we could call them "bunnies" or "entities of type 42" if you
> find conflicting connotations of "landing page" too strong. Personally
> I like "landing page".

I gave two constructive suggestions. First was to use the technology
available to you, and which is being promoted by W3C for associating
words on web pages with definitions, and definitions with labels.
Second was that the label ought not to be one that was already a term
of art in the same field, with a different definition.

> The ontology of these things is quite tangled. Our experience over the
> past ten years is that articulating what they are is a lost cause.

I have some thoughts about that. We could discuss that some time. I
don't think the confusion is necessary. I think the existing
specifications for RDF and OWL are quite good and that the W3C should
stick with encouraging their use. I don't see that as the path the W3C
is taking. Mixed/inconsistent messaging is one way to make it hard for
people to understand what's going on.

> A sensible ontologist like you would just stay as far away from them as
> they can, and stick to hash and 303 URIs (or else use a sensible
> private interpretation and give up on interoperability).

I consider my self a sensible engineer. There's a specified way for
accomplishing what is desired. It works, even if it isn't considered
palatable by some. Such is life. RDF/XML sucks to read but I love it
because it is a standard and I can depend on a message so formatted
being unmolested as it passes from here to there, assuming the spec is
followed. Compare, for instance, what you see in the hits for this
search on http://clinicaltrials.gov/ct2/results?term=neutrophil+109&Search=Search

Search in the hits for "109". You will see that many are cases of
mistransduction of 10^9 (a billion versus a hundred and nine). The
problem is that there isn't any specification that covers enough of
the systems this information has gone through to make sure that this
sort of mistake doesn't happen.

When I encounter a specification that *does*, I consider that a
serious accomplishment, and don't mind going through some hoops to
avert technical failure such as this.

As a sensible ontologist I might help you make clear what the
distinctions are. Dealing with developers or organizations that don't
want to conform to standards or don't have time is an entirely
different issue.

> Fortunately
> success here does not rely on ontology, it depends only on empiricism
> - what experiments do you do to test whether a set of JSON records, or
> an RDF graph, is consistent with reality.

That'll do. If I saw an official statement from the TAG saying that
was the goal I think we would be making progress.

> Explaining that is the objective I think we should aim for in crafting this document. I think
> that is doable.

I don't think I see *anything* that directly addresses this point in
the document.

-Alan

Received on Wednesday, 10 October 2012 17:25:50 UTC