(no subject)

From: Stefan Decker (stefan@db.stanford.edu)
Date: 01/10/01


i tried to answer Pats and Peters comments in one email:

PETER>RDF has no semantics.  It never has had a semantics.  I say this even
PETER>though Richard and Deborah have produced the beginnings of a 
semantics for
PETER>RDF.  Their effort only provides semantics for the portion of RDF
PETER>that has a fairly obvious meaning.  (It does not provide a complete
PETER>semantics for containers or for reification.)

PAT>Almost any expression of almost any formal langauge, and quite a lot of 
unformalised PAT>languages, can be represented as a graph. Graph-based 
notations for full first-order PAT>logic have been around for over a 
century now.  The first notations ever devised for PAT>logic were 
graph-based notations. So this observation isnt really much of an argument 
PAT>for RDF as such.

What kind of semantics does a directed, labelled graph have?
It's a graph - nothing more. RDF does not have semantics behind
it's graph structure. (There might be people which disagree with me here).

RDF is just a datastructure which allows a convenient access to the data.
Consider it a help for the ones who do the dirty work: programmers.
It simplifies their work by reducing the effort and amount of code
they have to write to process, query and integrate data, expressed in 
different languages.
Our experience (and that of others) show, that is easier and takes less effort
to process the data. Thats everything.

In short:
By putting our more sophisticated languages on top of the graph structure
we simplify the processing of the languages.

PETER>As with any syntactic system without a clear semantics, people using RDF
PETER>have had fights over what various RDF constructs are supposed to 
mean.   I
PETER>forsee these fights continuing ad nauseum.

Since the graph is pretty much defined, I guess you argue more about
RDF Schema.

PETER>DAML+OIL uses only a fraction of RDF.  It (purposely) does not use 
the RDF
PETER>constructs that are most open to misinterpretation.  Nevertheless, 
PETER>is on somewhat shakey grounds even with this restriction to the
PETER>more-obvious portions of RDF.

Why is the ground shaky if we define a syntax based on a graph structure?
Again, I say nothing about semantics - for me a triple is nothing more than an
entry in a database. What does a tuple in a database say about the content
of the semantics of the tuple? Of course the tuple has a certain semantics, 
since a
database can be formalized by model theoretic means (see the Reiter paper).
But still this does say nothing about the semantics of the content of the 
It might (e.g.) contain a description logic formalization of domain.

Some confusion might arise when we try to mix the tuple level and the semantic
level. It might be worthwhile to really define the interaction between 
these level -
I'am convinced there is much less interaction than currently assumed.
(A keyword is e.g. the confusion around wether or not to apply the closed 
assumption:  when I process a RDF model (a finite set of tiples) I 
automatically apply the closed world assumption when I test if a certain 
triple is present if the set or not.)

PAT>The existence of a graphical notation, on the one hand, and the ability 
to process and PAT>translate information by 'declarative means' (or indeed 
any other way), on the other, PAT>have absolutely nothing to do with one 

The knowledge how certain concepts are represented as a graph structure makes
it easier to process them. Thats all I'am saying. It reduces the effort
(e.g. in code writing time) by  (my estimation) an order of magnitude - 
which is
very worthwhile, since on the web we already have many different
representation languages, and we (despite our standardization efforts) will 
many more. If we make it easy to translate from and to our language
(in terms of code size and effort) we have an advantage.

PAT>Clarity and precision in translation are typically the end product of 
having a precise PAT>semantic specification, which RDF seems to be 
singularly lacking in.  (I know this is PAT>a controversial statement, but 
I would observe that members of the very committee PAT>that produced RDF 
and whose names are listed as authors on the source PAT>documentation 
apparently disagree with one another about the semantics of RDF and
PAT>RDFS, and no precise semantics was ever published, and apparently still 
hasnt been PAT>to this day.)
I completely agree with the first sentence:
Clarity and precision in translation are typically the
end product of having a precise semantic specification.
And thats what we try to do. Defining a clear and precise language on top 
of a syntactical
graph structure. If the  graph structure is ill defined somewhere we should try
to figure that out and correct it. But that should be not to difficult to 
get a graph right.

However, the processing of the languages (in terms of lines of code and
thus programming effort) is dramatically reduced by the usage of a 
datamodel like

PAT>It may for some, but it certainly does not for all. The vagueness and 
confusion (eg PATbetween >omplex syntax and reification) in the RDF 
documentation do not make the PAT>task of >ranslation any easier for anyone 
outside the RDF community.

You are talking about the transfer syntax. Only a few RDF parser writers, 
APIs would have to deal with the transfer syntax.
All the other people writing translators from whatever languages
to whatever else language operate from the data model and have a convenient
API to use it.

All the best,


This archive was generated by hypermail 2.1.4 : 04/02/02 EST