Notes about RDF M&S draft of 8th October

Hello
http://www.w3.org/TR/WD-rdf-syntax/
here are some notes and remarks about RDF M&S draft of 8th October.

It reached a version which is clear, although 
from my point of view there is still some details which are incoherent
with the whole spirit of RDF.

1- In section 2.2.1, it is said that either "ID" or "about" can be 
specified on a Description element, but not both.
Why can't we simply use "about" in Description, and create
a resource if the value of this attribute is not an URI and
does not exist ?
Example :
	<rdf:Description about="foo">
	<dc:author>My self</dc:author>
	</rdf:Description>
will create the resource "foo" and associates to it the (predicate,value)
couple (dc:author,"My self")

2- In section 2.2.1, paragraph starting with "Property names must always
be associated with a schema" is not clear for me.
The remaining explains that the property must be qualified...
What is the attended behaviour of an RDF engine when it finds a
non qualified element in a Description ? Must it simply ignore it ?
Is it an error ? 

If this behavour is out of scope of this draft, the mentionned sentence
should be modified as "Property names should always be associated with a schema"

3- At the end of section 3.3 the  the 2 Descriptions are not fully 
equivalent to the previous unique Description. In latter case, there is 2 bags,
in the former, one bag only. 
Regarding of the declaration of equivalence (section 2.1 : "Two RDF
expressions are equivalent of and only if their data model representations
are the same"),
as far as Bag are parts of RDF data model, equivalence in section 3.3
is wrong.

What is true it that these are equivalent in term of expressed statements.
Thus, last sentence of section 3.3 should be rewritten as :
	"Thus, with respect to the resources "foo" and "bar", the above
	example express the same statements than"
or
	"Thus, with respect to the resources "foo" and "bar", the above
	example means the same thing than"

or last, definition of equivalence should be changed to something like :
"Two RDF expressions are equivalent if and only if they express the same
statements."


4- In section 3.5 definition of aboutEachPrefix is confusing.

First, I would prefere to have only aboutEach attribute on Description
and to have a way to symbolically define a Bag in order to fill it 
with a set of resources, without explicitely write these.
E.g.:
	<rdf:Bag>
	<rdf:li prefix="http://foo.cm/doc" />
	</rf:Bag>

Second, if we envisage to have a definition of a set of URI based 
on prefixes, why don't use also regular expression ?
Prefix allows to describe (with strong hypothesis of structure of a site)
a tree of URI, but it does not allow to identify, for example, 
all Credits page of a Web site. These pages can be in different sub trees
and we could want to have a RDF predicate on all these.

Last, it appears to me that definition of a set of URI has nothing to
do with RDF specification. It is stated in section 2.1, in definition
of Resources that "Anything can have a URI; thee xtensibility of URIs allows
the introduction of identifiers for any entity imaginable."
Thus, the definition of a set of resources, and the way to define
this (prefix, regular expression, other...) is up to the definition
of URI.
If this is really needed, RDF draft should propose an extension of
URI, for example "rdfprefix:<uri>".
Then, example of section 3.4 could be written as :
  <rdf:Description about="rdfprefix:http://foo.org/doc">
    <s:Copyright>© 1998, The Foo Organization</s:Copyright>
  </rdf:Description>

In addition, as in point 3, the 2 examples of end of section 3.4
are not equivalent... 


5- It is now completely clear what is the meaning and the
objectives of the operation called "reification".
But I am not sure this should be defined in the RDF M&S spec.

Indeed, the properties RDF:predicate, RDF:subject, RDF:object and
RDF:type add a strong semantic to the corresponding statements.
This is not model, nor syntax related, but this is a descriptive
mechanism.
Then, I think this could be defined in a specific schema, apart from 
RDF M&S specification.
This could make clearer the reason why a reified version of
a statement must not be considered as the corresponding inline statement.
Until now, if the reasons why are clear, the way to specify a reified
statement - at the same level than inline statements - is confusing.

6- In section 6, the definition of formal namespace for the RDF spec should be
	http://www.w3.org/TR/WD-rdf-syntax 
instead of 
	http://www.w3.org/TR/WD-rdf-syntax#
The fragment identifier character has no reason to be used here.

(from RFC2396 :
   A fragment identifier is only meaningful when a URI reference is
   intended for retrieval and the result of that retrieval is a document
   for which the identified fragment is consistently defined.
)


7- In section 6, in the first item of list defining the triple,
the sentence 
"This expansion is generated by concatenating the
      namespace name given in the namespace declaration with the LocalPart of the qualified name. " should be removed.

The expansion of a qualified name is not RDF related. 
Then, first item should be rewritten :

"1.p is the qualified tag name (Generic Identifier) of E. "


8- As for point 4, section concerning aboutEachPrefix should be modified.

9- In section 6, in  the explanation of first simplication method 
("Each property and value expressed in XML attribute form by productions [6.3] and [6.10]..."), the "xml:lang" and "xmlns" starting attributes have
been removed from the creation of triple, but what about "xml:space" ?

More generally, as expressed in a previous mail, I am definitely sure
that *all* "xml" starting attributes must  be removed from the creation
of triples.
An attribute starting with "xml" will always add a XML information on the
*element* itself, on the manner it must be syntaxically treated.
It will not add any semantic information to the element !

If "xml"starting elements are not removed, any "xml*" attribute not listed
now will create triples which are not meaningful.


10- Concerning the inclusion in HTML, why don't 
 use the <OBJECT> element for RDF inclusion ? This will
make it HTML 4.0 compatible.


11- Section B.2
I'am not sure to fully understand what WG is expecting, but I think that :
a) the client must be able to ask for RDF data if present.
This can be done with the Accept header field in HTTP request.
For example :
	Accept: text/html;rdf=1, text/html
b) server should be able to indicate to client that RDF data exists.
This can be done with the Link header field in HTTP response.
For example :
	Link: <http://foo.com/doc.rdf>; rel="RDF"



Hope this helps

Regards
--
Olivier.Marce@inria.fr		INRIA, Direction du Developpement
Projet Mediaculture		Domaine de Voluceau, Rocquencourt BP 105
				F-78153 Le Chesnay Cedex (France)
				Tel: +33 (0)1 39 63 57 23/51 14(Fax)

Received on Friday, 16 October 1998 06:10:40 UTC