From: Stefan Decker ([email protected])
Date: 01/10/01
Hi,
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,
DAML+OIL
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
database.
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
world
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
another.
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
have
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
RDF.
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,
defining
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,
Stefan
This archive was generated by hypermail 2.1.4 : 04/02/02 EST