RE: A Rough Guide to Notation3

Before responding to your points, a question occurred to me that pretty much
encompasses my opinion re. N3 - would the RDF spec suite be easier to
understand if the diagrams were replaced with N3?

>I think that contrasting machine understanding and human legibility is a
>big mistake. Programming languages absolutely need to be understood by
>the computer but they also need to be readable and modifiable by humans.
>A good language is *as readable as possible* (for varying definitions of
>readable) without denying the computer its opportunity to understand.

From a pragmatic point of view, I don't entirely disagree with you. In
principle, I don't think this argument holds much water, after all text is
only available on computers because of several layers of abstraction. How
often is it necessary for a programmer to deal with data directly in terms
of bits in logic gates in chips?

There are plenty that would say that the main purpose of programming
languages is human understanding, with your proviso that they make sense to
the machine. The languages are intended to make it easy to put together
complex structures and algorithms. Paradigms like OO use ideas like
inheritance and encapsulation to build up these structures in such a way
that the information can be handled at different levels of granularity,
something that is particularly useful for humans.

But N3 as it stands is another low-level view of the RDF model like XML/RDF,
and the difference in the views conceptually is little different than
looking at relational data tables in tab-delimited or comma-separated forms.
Ok, so N3 is more human readable than RDF/XML, but it doesn't come for
free - a new notation has to be learnt and new (un)parsers and interfaces
have to be built.

>Text-based languages are interfaces between us and the computer,
>otherwise why use text at all?

A very good question, and history & practicalities figure highly - there are
a lot of good and well-established tools and techniques for exchanging and
processing XML, which happens to be text. So XML/RDF is imho well justified.
I suspect that if the developers of RDF and N3 had spent less time working
in text-based environments (Unix etc) and more time in graphical
environments (Squeak?) then the situation would be somewhat different. I
don't think it's a coincidence that the first graphic tool of note
(RDFAuthor) was built for the Mac.

>Somebody has to read the raw data because somebody has to write the
>tools that present the metadata to us in pleasant forms. Once again I'll
>ask, if we don't care about these people then why use text?

This may be justification for having a text representation of RDF, but are
more than one really necessary?
Of course it's possible to avoid N3 altogether, but my original point was
that the newcomer to RDF would first encounter RDF/XML (a syntax that is
bound to be misleading because of the XML's tree base) and then N3, a
semi-formalised syntax that bears little relation to anything familiar. Yes,
there's ntriples, but this is an even lower view of the information. The
graphic view used in the specs is tied to the model in a reasonably formal
fashion, and I think this could be extended profitably. Having said that, I
could see a place for a textual language that conveyed the information at a
more molecular level, and that's something the RDF query languages seem to
approach (although I would question the value of making it look like SQL ;-)

N4 anyone?

Cheers,
Danny.

Received on Saturday, 24 August 2002 05:23:13 UTC