xml-dev - RE: RDF, the "semantic web", and the nadir of AI (was RE: Realistic prop

[Robin Berjon <robin@knowscape.com>]

At 03:40 18/10/2000 -0400, Gavin Thomas Nicol wrote:
>> I don't know whether or not the semantic web will 
>> succeed, but the idea does make some sense. 
>
>Please explain it to us all... I've never really grokked it,
>and I used to work in AI...

I'm not sure it *has* to be looked at from an AI perspective. That would
probably miss a good part of it. The first sentence of
http://www.w3.org/DesignIssues/Interpretation.html is "The semantic web is
a computer system, a distributed machine which should function so as to
perform socially useful tasks". This doesn't tell us what it is, but the
emphasis on "socially" is imho important. It is not a ComSci thing, it's a
social thing (that may be facilitated by CompSci). The goal as I understang
it is "simply" to make the web a more usable graph.

For me the best way of understanding what "semantic web" means is to
understand it in it's vaguest possible acception: a web of "meaning(s)".
Right now if you are reading information on the web and want access say to
related information you have to rely on the source to provide with links,
or you need to use external ad hoc applications (for instance search
engines). Both are fairly crude ways of relating information, and neither
really attaches meaning to their targets. RDF, Topic Maps and XLink may
have different use cases, but they can already be used to better what we have.

The problem relating to AI lies in the degree of automation that maybe
required for the semantic web to be useful. It's a question of bridging
machine readability/usability and human readability/usability, and it does
send back directly to definition related problematics. I don't think that
the semantic web should make the web intelligent (inter-linked, ie so that
AI agents could truly link and interpret semantic links) but rather
intelligible (inter-linkable, ie so that automated agents better provide a
set of links, leaving the actual linking up to the human being needing them).

>The more important, larger problem is that even *if* you have all
>the assertions, they are
>
>  a) never complete
>  b) never correct (especially in the face of change)

Semantic != complete/correct. Humans can to a certain degree deal with
incompleteness and inaccuracy. If the meaning is carried clearly enough
then human interpretation can step in. Given that the web contains
information potentially put there by just about anyone in mankind, you get
the best of mankind just as well as the worst of it. Creating new axes
within that information is what is interesting (imho).

Imagine for instance that you are looking for information on fanatical
groups in general (religious, political, etc...). They will never link one
another for you, it would go against their way of thinking. Asking a search
engine for "fanatical groups" will yield nothing because they don't
describe themselves as fanatics. That's a shortcoming of purely textual
search. You'd have to search for all instances that you already know, which
means you'd miss a lot. If on the other hand the web was made more semantic
(small step by small step) you _may_ eventually be able to look for those
sources of information based on what you think best defines them ("we rule
the world, kill all the others, etc").

>This is *precisely* where namespaces fail: the semantics of
>the identifiers *will* change over time (unless one uses
>UUID's that are devoid of meaning), and hence will alter the
>semantics. In other words, the *language* they identify
>will change.
>
>For example, if I use 
>
>  <foo xmlns:j="http://www.ebt.com/jersey"/>
>
>what does jersey tell me about the meaning? Is it the
>cow, the island, or the sweater? 
>
>Even if you have a notion that I'm talking about cows, how
>does that affect *your* processor? Some binding step is
>missing here... a name is just a name. That's very different
>from semantics.

But the binding step isn't that hard to make. If you create a language
within a namespace and bind semantics to its elements, then you could
describe those semantics (for instance in RDF) and make them available
either as linked from the document instances, or in some sort of
repository. It's one (big) step better than relying on the actual name of
the element, it provides context.

I must admit that most of what I say is fairly vague, I'm just trying to
throw ideas around :)



-- robin b.
Those of you who think you know everything are very annoying to those of us
who do.