Re: Misunderstanding documentation protocols

Hi Jonathan,

Some comments below . . . 

On Fri, 2012-06-01 at 18:38 -0400, Jonathan A Rees wrote:
> In April I promised to answer you regarding your misunderstanding of
> "Understanding URI Hosting Practice as Support for URI Documentation
> Discovery" http://www.w3.org/2001/tag/doc/uddp/ . I think we've been
> over most of the terrain in the meantime, but I wanted to try to go
> over it again so that it's not left hanging.
> 
> If it sometimes sounds like I'm echoing you, that's fine.
> 
> Forget about URIs for a moment and just consider, say, English words.
> Consider the following ridiculous but illustrative idea: We define a
> "dictionary protocol" as follows: take any English word W, form the
> URI http://W.com/.well-known/definition , and do a GET of that URI.
> The content that comes back will be called (in the terminology of the
> protocol spec) a "nominal definition" or ND of the word. The protocol
> definition says that the intended use of the protocol is the provision
> of (correct) definitions of words; but this would not be a normative
> requirement of the spec as there can be no objective test for whether
> something is a correct definition of a word.

Okay, but this example is insufficient to characterize what's needed in
semantic web architecture.  

The quintessential use case of the semantic web is that a
semi-autonomous agent should be able to sensibly merge two RDF documents
that were authored independently, using common URIs to join related
information.  Framing the problem as communication between a sender and
receiver misses an important aspect of this use case.  If the problem
were only one of communication between a sender and a receiver, then
there would be no architecture need for the role of URI Owner.  But this
role is what allows independent RDF authors to use the same URI
definitions in a scalable and efficient way, and this is critical to
being able to sensibly merge independently authored RDF.

> 
> Suppose a community of agents take this up. Web servers start
> providing content at these URIs, and users start using "ND" in what
> they say to one another, such as "the ND of the word 'invasive' is not
> very good".

Okay.

> 
> Obviously the creation of the protocol won't change the meaning of
> messages written in English before the protocol definition was
> published, 

Agreed.

> and it will not have a role in the meaning of new messages
> where the author of the message is not aware of the protocol. 

Agreed.

> It is
> conceivable that agents composing new documents might check the ND of
> a word before using it, to decide how to use it; or search NDs to find
> words that express some meaning they want to express. But this would
> have no bearing on the expectations of senders and receivers in
> general. 

Disagree.  Such a protocol *would* have bearing on the expectations of
senders and receivers, because if it became widely accepted, there would
be social pressure to conform.

> NDs would not be binding on anyone (without their opt-in).

Right, but there's no architectural need for them to be binding either.
The notion of them being "binding" is a social or legal notion -- not an
architectural concern.

> 
> Obviously this system is vulnerable to confusion and attack. An ND
> might be quite good and provide excellent documentation that matches
> what the word actually means in English - it could be as good as the
> OED, it might provide many definitions, corresponding to various
> contexts of use, document format contexts, historical periods, etc.,
> perhaps even other languages. Such words will have a good "reputation"
> and over time the NDs could be treated by some agents or communities
> as authoritative. But in general, the content will be up to each
> server operator, and is arbitrary.  

Yes, and that's by design.

> It could change incompatibly over
> time, be wrong or misleading or outdated, source phishing attacks,
> appear differently to different readers (conneg-based attacks), etc.
> Relying on NDs from unvetted sources would be a bad idea.

Correct.

> 
> When the protocol is in use, the key question is the locus of
> accountability when something goes wrong. 

No, that is not a key question.  That's out of scope of what the
architecture needs to be concerned with.  From an architectural
perspective, if the receiver doesn't like what it receives then it can
look for something else.  If social expectations rise to the level of
becoming law, then a sender might be sued or prosecuted for sending
something "bad", but that is not the concern of the architecture.  

> Is the sender vouching for
> the reliability of (or granting authority to) the ND service for the
> words (URIs) in their message, or is the receiver only using ND
> services as a heuristic for figuring out what the sender *might* have
> intended, taking on full responsibility in case the retrieved ND is
> not in line what the sender meant? Is it sender beware or receiver
> beware? 

The web is designed to allow "anyone to say anything about anything".
That is inherently "receiver beware".

> Sender beware has been proposed. It would require opt in from
> all senders, past and future, which is impossible. 

I don't know what you mean by "sender beware".  

> Even if we restrict
> discussion to particular formats / contexts such as RDF, this is not
> how RDF or any other message format is specified today. The UDDP memo
> therefore assumes receiver beware. I tried to make this clear in the
> "risks" section, but apparently failed.
> 
> I'm not defending FYN, semantic web, or linked data; if anything I'm
> trying to expose to the light the architectural problems they elicit.

What problems?  The fact that someone can publish junk, or change the
definitions of URIs that they own is not a bug, it is a *feature*.
Relying on the market and social pressure -- instead of trying to solve
the "problem" of bad publishers or bad data at the architectural level
-- is one of the brilliant aspects of the architecture.

David

> You seemed to take the composition of the UDDP memo as an endorsement
> of its content, and it certainly was not.
> 
> ... I think it's important to note that FYN is not part of RDF, and
> not all uses of RDF suggest it. For example OWL (which has an RDF
> binding) doesn't imply FYN for interpreting URIs at all - consulting
> the web would actually be incorrect in the general case. The meaning
> of every URI, for purposes of the ontology in which it occurs, is
> defined locally in the ontology in which it occurs. (Of course it's
> nice if URIs are used consistently across all OWL ontologies; but
> there's nothing in the spec that requires this.) So I think the
> designers of OWL were aware of the weakness of FYN on some level. (OWL
> does use web-referring ontology version URIs which act like '#include'
> in C, and these affect the identity of an ontology. I suspect that for
> ontology version URIs, the community expectation is sender beware, but
> this would be an empirical question.)


> 
> Jonathan
> 
> On Wed, Apr 11, 2012 at 9:53 PM, Jonathan A Rees <rees@mumble.net> wrote:
> > Listen, don't answer my previous message as it doesn't address your
> > accusations that I subscribe to the incoherent and/or incorrect
> > theories that you misattribute to me. I will answer that in due time.
> 
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Monday, 4 June 2012 17:45:08 UTC