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