Re: (Part 1) Where did these syntax constraints come from?

From: pat hayes (phayes@ai.uwf.edu)
Date: 01/09/01


>Peter,
>
>one (among many) answers:
>RDF is basically known in the database community as semi-structured data and
>used for database and schema integration tasks.

Thanks for the tutorial, Stefan.

>It basically boils down to that every datamodel can be represented as a graph.

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

>If it is available as a graph declarative means can be used to 
>process and translate
>the information available (this is the approach we used to e.g. translate
>UML-XMI into DAML/OIL at http://www.interdataworking.com ).
>(if there is interest I can sent some references for older (1997) 
>and more recent papers
>(2000) about information integration).

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

Clarity and precision in translation are typically the end product of 
having a precise semantic specification, which RDF seems to be 
singularly lacking in.  (I know this is a controversial statement, 
but I would observe that members of the very committee that produced 
RDF and whose names are listed as authors on the source documentation 
apparently disagree with one another about the semantics of RDF and 
RDFS, and no precise semantics was ever published, and apparently 
still hasnt been to this day.)

>Directly specifying DAML+OIL in RDF makes it easy to translate to 
>and from other
>representation formats to DAML+OIL (and thus encourages the use).

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

>Translation is definitely necessary, since most of the available 
>information is not
>described in DAML+OIL.

I imagine that anyone who could write an RDF-OIL translator could 
just as easily write an RDF-KIF or an RDF-CG translator. (Or into 
just about any other logical language with minimal expressive powers: 
in fact, I suspect one could map RDF into propositional logic with a 
bit of ingenuity.)

Pat Hayes

>All the best,
>
>        Stefan
>
>At 07:58 AM 1/8/2001 -0500, Peter F. Patel-Schneider wrote:
>>From: Frank van Harmelen <frankh@cs.vu.nl>
>>Subject: Re: (Part 1) Where did these syntax constraints come from?
>>Date: Sun, 07 Jan 2001 23:27:36 -0100
>>
>> > This is not what we had wanted to suggest. We believe the situation to
>> > be as follows:
>> > - DAML+OIL assigns a specific semantics to certain RDF graphs
>> >   (in this respect, it is exactly similar to RDF Schema)
>> > - It's the underlying RDF datagraph that counts, not the particular
>> >   surface RDF syntactic form that is used to describe it
>> > - RDF allows for multiple syntactic forms for the same 
>>underlying datagraph
>> > - since DAML+OIL assigns semantics to certain RDF graphs, DAML+OIL
>> >   should also be insensitive to the particular syntactic form used
>>
>>It seems that the the issue of DAML+OIL being specified in terms of RDF
>>triples has been decided, but I don't understand why this is so.  Can
>>someone enlighten me as to why we are going through so many hoops to end up
>>with what is, in my opinion, an undesirable result?
>>
>>Peter Patel-Schneider

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes


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