Doug F, Doug McD, and Pavithra,
DF> TimBL designed the Semantic Web "layer cake" on which RDF sits on top
> of XML and supports the semantic layers. He has recently pushed Linked
> Data as part of the Semantic Web, following that layer cake meme.
>
> Remember that the outstanding work he did in 1991 was also based on
> defining an underlying syntax. The idea is that for widespread computers
> to communicate, they need to be able to handle the same syntax.
Tim BL's original book and web postings about the Semantic Web created
a lot of enthusiasm, and I wrote a note to an ontology list in 1998
that strongly
endorsed the idea. But I was less enthusiastic when
I saw the layer cake at a conference at Stanford in 2001.
I agree that "for widespread computers to communicate, they need to
be able to handle the same syntax." But mapping one syntax to another
is trivial. Programmers have done that successfully since the 1950s,
and formal grammars enabled them to write highly efficient, general,
and accurate translators since the 1960s.
The critical issue is not "same syntax", but "same semantics."
At the end of this email is a copy of my earlier note about
"How to define a standard." That note is fundamental to the
way the Semantic Web must evolve, if it is to survive as a
*semantic* web, not just a syntactic web.
DF> My issue with RDF is not with it being exchanged on the web in XML --
> why should semanticians care about messaging formats -- but in its being
> limited to
triples, which XML is not. This is a bottleneck that makes
> encoding a semantic language into RDF/XML difficult, raising complications
> for expressing contexts, attaching meta-assertions to RDF statements, and
> expressing ternary and higher arity relations.
I strongly agree. But semanticians must care about letting the
exchange format become the tail that wags the semantic dog.
Tim BL's original book and web postings about the Semantic Web created
a lot of enthusiasm, and I strongly endorsed it in an email note to
an ontology list in 1998. But I was less enthusiastic when I saw
the layer cake at a conference in 2001. For a brief summary why,
see slide 21 of
http://www.jfsowa.com/talks/iss.pdfThat slide shows the huge changes in the upper levels of the layer
cake in the past ten years. The RDF
layer has now slipped under
the XML layer with the more recent RDFa. That indicates fundamental
shifts, which I discuss further in the remaining slides of iss.pdf .
DF> However, an XML message envelope around an _expression_ in some
> language which can be stripped in a standard fashion after transmission
> over the web should not be considered a burden. A local system that
> transliterates into and out of XML need not store its data in XML, nor
> use XML-based query techniques.
Yes, but it is easy to strip off <script>...</script>, which causes
a minimal amount of overhead. The bloated RDF syntax causes a factor
of 10 overhead in both transmission time and processing time. Methods
for compressing the bloat can reduce the transmission time, but at
the expense of even greater processing time. Even worse, the bloated
syntax creates a serious danger of
bugs. (See the note copied below.)
PK> As technology stacks are defined, they have to be flexible meet
> various needs
> ...
> Keeping simple things simple is important and not to confuse everyone.
Absolutely! The problem with RDF is that it started with the simplest
possible semantics, namely a conjunction of triples (A B C), and buried
it in a syntax that even Tim Bray admitted he could not write correctly.
The bulk of the SemWeb technology stack is bogged down in extracting
data that LISP processed with three operators: CAR, CDR, and CONS.
LISP was 50 years ahead of the Semantic Web. In syntax, it still is!
DMcD> ... how the discussion of these technicalities might be aimed
> at helping enterprise architects portray the fruits of their labors.
The semantic forest has been lost in syntactic trees. My goal is
to integrate *all* semantic
systems around *semantics*, not syntax.
See the iss.pdf talk for further suggestions.
DMcD> I have, actually, over the years, learned to expect it is a waste
> of time to talk about anything over here but ontology tools --
> as opposed to issues of actual enterprise *meaning*, which is where
> I keep trying to find a purposefulness for ontological thinking
> (since at least 1996):
http://enterprisology.com/node/128That's a good article, but I'd like to suggest one addition:
the author's name (in this case, yours) is traditionally placed
immediately after the title of an article.
John
-------- Original Message --------
Subject: How to specify a standard
Date: Thu, 02 Sep 2010 22:17:03 -0400
From: John F. Sowa <
sowa@xxxxxxxxxxx>
To:
architecture-ecosystem@xxxxxxxEd,
This is a critical issue, which cannot be left to folklore about
how standards tend to evolve. It must be addressed head on.
On 9/2/2010 11:41 AM, Ed Barkmeyer wrote:
> If one standard serialization format is good, surely 7 such standards
> is much better. In point of fact, one standard serialization format
> that is no one's favorite will guarantee successful interchange,
> while two standards will make interchange more difficult, and more
> than two makes it impossible.
The first sentence may or may not be true, but the second sentence
is *false* in general. There are indeed many cases for which it is
true, but the cases that are essential for OMG and
the Semantic Web
are ones in which that statement is false.
The cases for which it is true include software systems that define
the syntax precisely, but leave the semantics vague. As an example,
consider the C language, which was developed at AT&T to implement
Unix on a PDP-11.
The syntax of C was well defined, but the semantics was very loose.
However, the Unix system served as a very large suite of test cases
that imposed strong constraints on the C semantics. Any compiler
for C that could generate code for running Unix on another platform
had to be strongly compatible with the original C compiler. Even
then, there were loose ends that required further debugging on
each platform to which Unix was ported.
That kind of implicit specification is not acceptable for logic.
Common Logic is an extremely small language, whose semantics is
completely specified in 6 pages. It
is possible to define formal
mappings from the abstract CL syntax to and from an open-ended
number of different syntaxes in such a way that logical equivalence
is not only provable, but *guaranteed* by the mapping.
The major weakness of XML-based notations is that the angle brackets
have many nooks and crannies into which people are tempted to stuff
all kinds of extraneous information, which may or may not have
semantic significance. That is the problem with RDF that Tim Bray
criticized years ago. In general, a notation that looks ugly is
in serious danger of having latent bugs and semantic loopholes.
Therefore, the XML specification for RDF is totally unacceptable
for a standard. N3 is far simpler than the XML-based notation,
largely because it lacks the XML nooks and crannies. Furthermore,
N3 is the notation that developers generally use, because the
base-level RDF is far too
complex for human use.
But my recommendation is even simpler: the official standard
for RDF should be specified in Common Logic. See the excerpt
below, which is taken from my previous note.
As the CL version shows, the amount of semantically significant
information in RDF or N3 is trivial. Everything else in RDF
is semantically irrelevant commentary.
Logicians define very precise logics because they keep the
specification small. CL is an example. They also ensure that
their mappings to different syntaxes are provably equivalent
by keeping them so small and simple that every aspect of the
mapping can be exhaustively tested.
The UML diagrams and other modeling languages are intended to
specify software systems. We cannot tolerate any ambiguity or
looseness of any kind in those languages. Their semantics must
be defined in terms of a logic whose
foundation is as small and
compact as CL.
If you have such a tiny core semantics with very small mappings
to other notations, you can guarantee that all those notations
have identical semantics. But if you start with a huge, loosely
defined kludge such as the XML-based definitions of RDF, you
cannot avoid ambiguities and loose ends, even if there is only
one specification document and one syntax.
John
__________________________________________________________________
I would point out that N3 has a simple mapping to CLIF. Just take
any set of triples of the form A R B and move each R to the front:
(and (R1 A1 B1) (R2 A2 B2) (R3 A3 B3) (R4 A4 B4))
In CGIF notation, you can even omit the "(and" :
(R1 A1 B1) (R2 A2 B2) (R3 A3 B3) (R4 A4 B4)
RDF also permits "blank nodes", which, as Pat observed, could be
expressed by existential
quantifiers. For example, if A2, R3, and B4
are intended to be blanks, one could write
(exists (A2 R3 B4)
(and (R1 A1 B1) (R2 A2 B2) (R3 A3 B3) (R4 A4 B4)) )
Following is the equivalent in CGIF notation:
(R1 A1 B1) (R2 [*A2] B2) ([*R3] A3 B3) (R4 A4 [*B4])
The subset of CL with just these features is a perfectly acceptable
dialect, and it has a direct mapping to N3 and to the semantically
significant core of RDF.
_________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/ Config Subscr:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ Unsubscribe: mailto:
ontolog-forum-leave@xxxxxxxxxxxxxxxxShared Files:
http://ontolog.cim3.net/file/Community Wiki:
http://ontolog.cim3.net/wiki/ To join:
http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1JTo Post: mailto:
ontolog-forum@xxxxxxxxxxxxxxxx