Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: SEMIS Bulletin



John F. Sowa wrote:

> I believe that it's a mistake to associate any kind of semantics
> with names of any kind.  I also believe it's a mistake to make the
> naming scheme "closely related" to any kind of "technology suite".

This is a substantive criticism of the Sweb and its use of URI's.
And it is related to a larger issue in Web Architecture, which
based on recent discussion in the W3C Technical Architecture
Group (TAG) seems to still be unresolved.  Pat Hayes is
involved in those discussions.

PH:
http://lists.w3.org/Archives/Public/public-webarch-comments/2004JanMar/1057.html

Tim BL:
http://lists.w3.org/Archives/Public/public-webarch-comments/2004AprJun/0001.html


It involves what the Web architects mean when they say
resources, and how to identify them.  One side seems unwilling
to distinguish between computational information resources and
entities in the world beyond digital computers; and URI's can
mean a pipe or a representation of a pipe (or Magritte' "ce ne pas un
pipe" painting, or a JPEG of it). The other side seems willing
to distinguish information resources, from the larger containing
class of entities in the world.  There can be some conventions,
using the # delimiter of fragment entities in the http:// scheme for
example, that will allow distinguishing the information resource
from what it is about.
I think we can use ideas about information flow to clarify things.
If semantics is about how the types is a linguistic classification
(of inscriptions or utterances classified by their syntactic
structure) is related to a domain classfication (situations in
the domain of discourse, classified by their regularities), then
we can study their infomorphisms and perfect and imperfect
information flow.  In particular, we can also construct
semantic languages that formalize certain shared aspects
of the domain of discourse, and study infomorphisms from
linguistic representations (e.g. a web page with a bibliographic
citation for display) and what they are about (a formally
defined directed labelled graph, using Dublin Core properties
to label edges, and URI's to label nodes).

I think John's comment that "it is a mistake to associate
semantics with names" refers to the situation where names are
built in too tightly to the semantic types.  I think at least
some Web architects, those willing to distinguish information
resources from resources in general, want at least URI's
with fragment identifiers in HTTP + HTML/XML to
be about types in the linguistic classfication, to be about
the information resource retrieved by dereferencing the
URI with an HTTP GET.  At the same time, I believe they
see it as a social problem to ensure that those representations
are reliably about entities in the world, something that
web standards cannot enforce but only encourage. And
it is permissible (and certainly not preventable) for people
to use URI's to name entities in the world directly, without
a mediating represention.  There certainly could be useful
URI schemes that would want to do that, for identifying
actions in a robot or states in real computer systems
being managed, as examples.

I believe some of the confusion arises from whether we are
using URI's for tokens (in the linguistic representation,
in the world, or in a semantic formalization of the world)
or for types.  I think the clean answer is URI's in general
are about persistent tokens in the world, and HTTP
URI's with fragment identifiers in an HTML anchor or
XML link are first about representations that can be
retrieved via a hypertext protocol, and additionally about
what those representations describe.  URI's in some RDF
metadata are about tokens in a formalization of the domain
of discourse, and we can design technology to allow
information to flow from the linguistic represenations in
HTML to the metadata in RDF. (A lot of this had better
be automatically generated, I don't think hand coded
metadata will get us very far, not even for 15 Dublin
Core properties).
Now tokens in the world change over time (they are
hylomorphic particulars, not ideal forms), but  we can, as a
social objective, expect that types describing them will be
consistent enough for us and our software agents to use.
URI's may be seen  to be about types, but they are useful
if they are about tokens.   Adding to the confusion is that we
are not talking about one classification, but two or three.
The URI is embedded in an HTML document anchor,
it is used to label nodes in Dublin Core metadata, and
it somehow corresponds to certain entities in the world
that perhaps change over time but retain identity.

If John's claim is consistent with this (and please correct
me if I am misreading or reading stuff into it), I agree
that it is a mistake to associate names too tightly with
the semantics of types.  Names belong more with the
pragmatics of tokens, and the semantics should be independent
of them.  And we shouldn't design that kind of dependence
into a system of names (URI's) that we want to be widely
used, much less build in dependence on a particular
technology suite.
On the other hand I also don't think the Web Architecture
and the Semantic Web are fatally flawed in this regard.  I think
Tim Berners-Lee's proposal, not yet a consensus in the TAG,
that http:// URI's with fragment identifiers in HTTP+HTML/XML be
primarily about representations or information resources (after
all we are talking about a scheme for hypertext here), but that
URI's in general (resources, possibly in the world beyond
computers) are not so constrained, is a step forward.

I think there is an ontological problem, and it can be cleared up
using tools like information flow.  So I don't think everybody will
unify on one point of view, but we can make a lattice of theories
about the Architecture of the Web and the SWeb, and we
should be able to get from my world view to your world view,
and the other way around, perhaps losing some information (which
we maybe can keep track off) along the way.  We don't have
to agree on an upper ontology (after all, Plato and Aristotle couldn't),
but we can agree that certain meta level tools let information flow
from my system to your system, no matter how imperfectly.
Ontologist, heal thyself.

I do hope SUO can play an important role in this regard,
but we had better start getting more practical work done. The
gap between IFF theory and practical integration of populated
ontologies is still too big.

> The original URLs were based on the Unix file system -- trees with
> cross links -- tied together with the Internet naming scheme as
> the top-level tree that ties together all the little trees.  All the
> other naming schemes are either trees with cross links, simple trees,
> or flat lists (which are very simple trees).  Any of them can be put
> into a universal scheme by attaching them at some node of the upper-
> level tree.  The things that the names point to have the semantics;
> the names themselves should just be globally resolvable pointers.


Hmm, the URI's themselves are opaque strings, the file system
trees may be accidents of the historical derivation of certain
schemes (ftp:// and to a lesser extent http://), but applications
shouldn't depend on those details.  It isn't a defect of URI's.

> PH> ... Part of the reason is precisely the 'simpler links' that you
> > mention so casually (which are certainly not used in simple ways,
> > eg check out what Google does with them).  The WWW isnt just
> > another network; if it were, it would just be the Internet: so
> > it evidently is more than just that.
>
> That's what I said.  The original WWW got an enormous amount
> of power by adding a tiny increment to the elephant.  I'm not
> complaining about that.  What I reject is the idea that they
> can be successful in semantics by adding more decorations
> to the tiny increment while ignoring the elephant.
>
> PH> ... All of the W3C efforts are designs by committee (do you
> > think that the ISO is going to be any different??) so one should
> > not think that because something is finally rejected that it has
> > been ignored. There are still some energetic LISPers working
> > on the SWeb as a kind of underground army, in any case.
>
> The original WWW was great because the basic structure was
> designed, implemented, and widely used *before* the committees
> got hold of it.  Then the committees did some good work in
> filling the holes, smoothing the rough edges, and adding
> decorations.  Committees are terrible at design, but very
> good at criticism.
>
> The weakness of the semantic web is that the committee took
> charge from the beginning.  The people who formed those
> committees would have done much better if they had gone off
> in small groups, implemented some competing projects, and
> then got together to compare them.
>
> PH> ... I agree with the common logic-based foundation, as of
> > course do many in the SWeb community. Its much harder to obtain
> > agreement on a *particular* logic-based foundation, however.
> > For example, one highly influential and vocal contingent insists
> > that any viable Web logic must be decideable. Others insist that
> > it must be nonmonotonic.
>
> That's committee talk.  I make note of their points and go off
> to design my own, very general framework, which includes all
> of them as subsets.  I don't claim to be omniscient, and I
> recognize the need for help, suggestions, and criticism at
> various stages.  And I would be very happy to see other
> people work on similar kinds of designs.  Then we can meet
> periodically and borrow ideas from one another.  I don't
> know the outcome:  perhaps we'll all converge; maybe we'll
> end up with a few competing designs; or we might all give up.


This is a nice sentiment, that I think can move us forward.  You
have in the past endorsed IFF, do you have specific ideas
about how it can be used to relate your KR book upper ontology
with OpenCyc or SUMO?  It wasn't used in MSO, or were
there elements of PM's approach that already embodies some
IFF elements?

Cheers,

Fred

- - - - - - - - - -

Frederick B. Kintanar
Cebu City