W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 1999

Re: www-rdf-interest@w3.org

From: Stefan Decker <stefan@DB.Stanford.EDU>
Date: Tue, 16 Nov 1999 18:40:25 -0800
Message-Id: <4.2.0.58.19991116181811.00b484f0@db.stanford.edu>
To: www-rdf-interest@w3.org
Hi Tim,

some comments:

RDF-Property element
--------------------

Is far as i understand it (with Sergys help & interpretation)
the section "RDF-Property Element" tries to connect "legacy" XML-documents
and  RDF-specifications.

While this is certainly a good idea, it is far away from
simplifying the syntax of RDF.
This problem of defining a RDF syntax should be split up in two areas:
	a) Specifying a simpler RDF syntax
	b) Annotating XML-documents, such that the content of "legacy" XML
	   documents are semantically accessible for RDF applications

a) + b) are separate issues and should be dealt with different
proposals and languages.

Concerning a) i completely agree with Sergeys proposal.
The goal of that proposal is:
  "Define a syntax that makes it easy for programers to create applications"

The current RDF spec and also your proposal has the aim:
   "Define a language that makes it convenient for people to create RDF
    (it they have understood the language, which is the crucial point).

RDF will be used and created by machines, NOT users.
So make it easy for programers to create programs.

Regarding b) (Annotating XML-documents):

a student of mine has written a thesis about annotating
  XML-documents  with respect to an ontology, which also solves the problem
of annotating tables and lists (you don't want to annotate every entry).
If someone is interested, i can send the thesis out. At least that could be 
a first proposal.)


RDF-Opaque
----------
To have a notion what an RDF-parser/consumer understands is certainly useful.
What needs to be introduced is some kind of relationship
between an RDF-Schema (ontology) and the piece of
software that is able to handle RDF-data represented
using that ontology. However, this is probably something that
could be handled by RDF-schema and should not influence
the RDF syntax.


While i personally appreciate to have the possibility to
write logic statements in RDF (and indeed in some discussion
with AI people RDF was criticized for not being that expressive)
But we should be very careful introducing something that people
will not understand.
And the other side choosing an
to expressive formalism will end up in non terminating
inference engines on the web and even more difficult problem.

If the basic notation (semantic networks) falls through,
then the more powerful does also.
Or to put it another way: i would not introduce XML before HTML is settled ;-)

Examples for rdf:for and rdf:about
----------------------------------
rdf:for and rdf:about also complicates the syntax, because
an parser has again to deal with the nesting level.
And even a user has to remember on which level he is.


RDF:Description
---------------
 >If the rdf:about attribute is present it indicates that the node 
represents a resource (document) whose URI is that give.
 >That attribute may be omitted.
What does it mean if the attribute is omitted?
What is the subject of the statement? How can be referenced?

RDF:Property
------------
 > There are times when using an XML element name for a property may be 
difficult or
 > impossible, such as when there are many prperties to be
 > listed, each from different namespaces, or when the property must take 
the value of the variable.
 > (Yes, I understand this takes RDF out of first order
 >            logic but our ability to quote statments and refer to them I 
think makes that step anyway).
I don't understand this sentence.
The ability to quote statements and refer to it does not take RDF out of 
first order logic.
One can think of a statement as a fact in FOL:

true(rdfstatement(subject,predicate,object)).

subject, predicate and object are just constants in this language.


Making a statement about a statement is simply another facts:

true(rdfstatement(rdfstatement(subject,predicate,object),predicate1,object1)).


However this is not the representation of the tripel format as defined in 
the RDF-spec.
However, both representations are equivalent and can be transformed:

The actual representation of a tripel is in the RDF Spec:

tripel(subject,predicate,object)
Reification is:

tripel(id,type,statement)
tripel(id,"subject",subject)
tripel(id,"predicate",predicate)
tripel(id,"object",object)

A new statement about that statement is:

tripel(id,newpred,newsubj)

Both. the first representation and the reified one link together by adding 
two rules:

true(rdfstatement(S,P,O)) <- tripel(S,P,O).
true(rdfstatement(rdfstatement(S,O,P),NEWPRED,NEWSUB) <-
		tripel(id,"type","statement"),
		tripel(id,"subject",S),
		tripel(id,"predicate",P)
		tripel(id,"object",O),
		tripel(id,NEWPRED,NEWSUB),
		NEWPRED not in { "type", "subject",  "predicate",  "object"}.


So we are fortunately inside FOL.
(Also the translation from the second to the first syntax can be done by 
rules, we just need
a Skolem-function for generating a unique ID for the statement.)


Thats it. Hope it makes sense.

Ciao,
	Stefan
Received on Tuesday, 16 November 1999 21:40:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:42 GMT