RE: yet another simplified RDF syntax: N-triples + abreviation

> Assembly and C exist for performance reasons. If it is possible to make
> a "Basic of N3" and it can perform as well as assembly language, then
> why invent assembly language and machine code? Just use Basic. Put Basic
> in the CPU. ;)

Assembly exists because it maps directly to machine code. Machine code
exists because that's how the machines work; any less abstraction and you
are down to setting individual bits to 0 or 1.

C, Basic, and other languages exist at different levels between human
ease-of-understanding and the underlying machine code.

A KR system at some point becomes machine code (either that or it uses
magick :) I think RDF is closer to the machine code than KR (or should be),
with advantages and disadvantages. (It's also particularly well-suited to
the web - but that's a different thing, no doubt a webbier KR could be built
if one were desirable).

> I'm not arguing FOR KR or AGAINST N3.

Neither am I, and I certainly don't want what I said to be clouded by
language snobbery (which was why I described RDF/XML as a *poorly written* C
:) Metaphors are poor tools at the best of times.

 I am arguing against a line of
> thought that I have seen too many times: "X isn't as easy to
> read/edit/understand as Y, but that's because it isn't designed for
> human beings to deal with." As you point out, in the end, human beings
> ALWAYS have to deal with it. It is human beings who instruct the
> computer on how to deal with it. Therefore, human factors issues should
> always be considered carefully.

Indeed n3 is a human-readable view on something that is inherently not
human-readable. It's value comes in giving us a better way of looking at
this than examining the rows or bytes that the internal triple store is in.
Hence the more human-readable it is the better, but it's an "honest"
representation of something happening at a non-human level. Hence my
comparison to assembly. If n3 loses that "honesty" it becomes something
else. That something else might be useful, and hence have a place, but it
would no longer be the tool it currently is.

Hence rather than arguing for or against n3 or KR, I'm arguing for both of
them - but for different tasks.

Received on Monday, 25 November 2002 07:54:10 UTC