Re: Semantic web architectural requirement [was Re: Squaring the HTTP-range-14 circle]

On Tue, Jun 21, 2011 at 9:06 PM, David Booth <david@dbooth.org> wrote:
> On Tue, 2011-06-21 at 17:52 -0400, Alan Ruttenberg wrote:
>> On Tue, Jun 21, 2011 at 5:06 PM, David Booth <david@dbooth.org> wrote:
>> > [Moving this comment to the AWWSW list, as I think it will be more
>> > appropriate there.]
>> > Following up on:
>> > http://lists.w3.org/Archives/Public/public-lod/2011Jun/0362.html
>> >
>> > On Sat, 2011-06-18 at 23:05 -0500, Pat Hayes wrote:
>> >> Really (sorry to keep raining on the parade, but) it is not as simple
>> >> as this. Look, it is indeed easy to not bother distinguishing male
>> >> from female dogs. One simply talks of dogs without mentioning gender,
>> >> and there is a lot that can be said about dogs without getting into
>> >> that second topic. But confusing web pages, or documents more
>> >> generally, with the things the documents are about, now that does
>> >> matter a lot more, simply because it is virtually impossible to say
>> >> *anything* about documents-or-things without immediately being clear
>> >> which of them - documents or things - one is talking about. And there
>> >> is a good reason why this particular confusion is so destructive.
>> >> Unlike the dogs-vs-bitches case, the difference between the document
>> >> and its topic, the thing, is that one is ABOUT the other. This is not
>> >> simply a matter of ignoring some potentially relevant information (the
>> >> gender of the dog) because one is temporarily not concerned with it:
>> >> it is two different ways of using the very names that are the fabric
>> >> of the descriptive representations themselves. It confuses language
>> >> with language use, confuses language with meta-language. It is like
>> >> saying giraffe has seven letters rather than "giraffe" has seven
>> >> letters. Maybe this does not break Web architecture, but it certainly
>> >> breaks **semantic** architecture.
>> >
>> > I don't think that's correct.  AFAICT what's important for the semantic
>> > web from an architectural perspective is the following:
>> >
>> >  The client must be able to use a simple, architecturally
>> >  authoritative algorithm to determine, with full fidelity,
>> >  the URI owner's formally expressed identity for the resource.
>> >
>> > To pick this apart and explain what I mean:
>> >
>> > Why "simple"?  To facilitate widespread uptake.
>> >
>> > Why "architecturally authoritative"?  So that everyone knows how the
>> > architecture is supposed to work.  This is like having an authoritative
>> > specification for HTTP: you don't want different people having different
>> > ideas about how HTTP is supposed to work.
>> >
>> > Why "algorithm"?  So that it can be done by a machine.
>> >
>>
>> Below is where your error is. The fact of the matter is that
>>
>> a) current representation languages do not allow us to say all we mean
>
> Agreed, but we can still say *enough* to make useful applications.

Granted.

>
>> b) most people aren't even skilled enough to say what can be said
>> using these languages
>
> Okay, but I don't see how that is relevant.  There is no requirement
> that everyone be able to write quality RDF.

There is if you a) say that the only meaning of a term is the written
RDF and b) that people shouldn't change what they initially write.

>
>> c) even among the people who are skilled enough with the formalism,
>> there remain difficult ontological issues that need to be addressed in
>> order to effectively communicate formally.
>
> What issues do you mean?

Ask Pat about liquids. Or try to figure out how write logical
expressions that give the correct entailments for license, contract,
or other legal matters.

>> So there can not be "full fidelity" (in the usual sense of the word)
>> without human intermediation somewhere in the system, for a number of
>> reasons.
>
> I explained what I meant by "full fidelity", and I clearly excluded
> semantics that require human intervention, because the goal is fully
> automated machine processing.  Think of "full fidelity" as "having the
> same formal entailments".  If the RDF, OWL, etc. specifications cannot
> assure us of having the same entailments then they need to be sent back
> to their working groups and corrected.

This is not "full fidelity".

Look, I could make the following definitions:

peace: a server that replies to SPARQL queries at http://sparql.neurocommons.org
love: contains all the obo foundry ontologies
understanding: computes entailments for some OWL assertions

And then I could publish my guide nirvana in which I write:

Myth 1: Peace, love and understanding is not achievable. Follow my
recipe and you will get there.

And when someone calls me on it, I could say: But, I gave you my
definitions of peace, love and understanding!

That's what I see your use of "full fidelity" in this context as.

>
>>
>> Suggesting what you suggest below therefore
>>
>> a) Encourages miscommunication, because full fidelity communication
>> isn't feasible and you encourage people to say anything consistent
>> with the published assertions *even if we all know it doesn't make
>> sense*.
>
> "Making sense" is irrelevant if it is useful to applications.

??

> Modeling the world as flat doesn't "make sense" in that the real world clearly is
> not flat, but still such data can be useful for *some* applications, and
> it may even be *better* for some applications than data that more
> accurately describes the world, because it is simpler.

Absolutely. But in an ontology we would call that a *model* of the
world and we would be able to tell the difference between the
approximations it gives and what actually happens, and assess whether
the difference is acceptable for the application.

But you say: The world *is* flat.

>> b) Discourages careful thinking, by suggesting that whatever people
>> write makes sense and is adequate and sensible
>
> I have never made that suggestion.  Where did you get that?

By promulgating the idea that the URI owner can say whatever they want
and that we should listen to it. Even if it doesn't make sense, is
misleading, or just plain wrong.

>
>> c) Dismisses one of our most powerful tools - our ability to
>> interpret, relate what is said to what is known, fix things, and
>> evolve our representations accordingly.
>
> By "representations" I assume you mean URI declarations or definitions.

I mean kr-representations. Information artifacts that are used to
represent our world and its constituents.

> I am not exactly dismissing our ability to interpret and relate what is
> said to what is known.  A human or a sophisticated application may still
> do those things if it chooses.  But I *am* dismissing it from semantic
> web architecture, because semantic web architecture is about enabling
> *machine* processing, and global, lossless communication would not be
> achieved if it required human interpretation or being related to "what
> is known", because those things are subjective.

Lossless communication will be the effect of your advise, because it
doesn't put enough emphasis on assertions making sense.

>> d) Along with your URI owner advise "URI owner responsibility 1: When
>> minting a URI, the URI owner (or delegate) SHOULD publish a URI
>> declaration [Booth2007] at the follow-your-nose (f-y-n) location,
>> containing core assertions whose purpose is to constrain the set of
>> permissible interpretations [Hayes 2004] for this URI. These core
>> assertions SHOULD NOT be changed after their publication." condemns us
>> to continue to use the inadequate representations forever.
>
> No, that is a "SHOULD NOT", not a "MUST NOT".  If you *choose* to have
> an unstable URI declaration that's fine as long is you publish your
> change policy so that RDF authors can decide whether they wish to use
> your URIs or not.

It is *your* characterization that a URI is unstable if the assertions
associated with it change.
In all of the OBO ontologies, the standard aimed for is that a URI is
unstable if its denotation changes.

Your characterization says that fixing mistakes implies that something
is "unstable". Mine is that fixing mistakes increases the value of
data.

> Change policy is covered in the fourth bullet of this
> section:  http://dbooth.org/2009/lifecycle/#other

I prefer http://obi-ontology.org/page/OBIDeprecationPolicy which is
based on actual experience with the GO over the last (at least) 10
years.

>
>>
>> All you say about formal statements should be recast as tutorial about
>> how a machine *will* interpret the assertions. The lessons learned
>> should be that what you say will affect how reasoner concludes and
>> therefore might effect some system you care about.
>
> No, this is not just advice to application developers.  It is system
> design.  It is about designing the semantic web as a whole to have
> certain desirable properties.  Different architectural design choices
> result in different properties of the system.

Then it is bad design and my advise to the reader is to disregard it.

>> But the lesson
>> should not be that this elevates these to where they are considered
>> truth. The assertions you make are in the service of truth, not the
>> other way around.
>
> I am not advocating that anything be considered truth.  Truth is
> irrelevant here.  This is about system design -- not philosophy.

We differ, probably irreparably, here. I am a system builder and have
been one for a long time. Certainly in my case truth matters.

-Alan

Received on Wednesday, 22 June 2011 05:33:22 UTC