W3C home > Mailing lists > Public > www-rdf-comments@w3.org > April to June 2002

Re: comments on the current clutch of working drafts

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Thu, 30 May 2002 16:09:52 +0100
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
cc: www-rdf-comments@w3.org
Message-ID: <1838.1022771392@tatooine.ilrt.bris.ac.uk>

>>>"Peter F. Patel-Schneider" said:
> Comments on the Syntax Specification:
> In general the new syntax specification is a giant step forward.  It
> finally makes RDF/XML real XML.  


> I do not understand why the information set nodes are transformed into a
> sequence of events, however.  Why not just work directly on the information
> set nodes?

To get around various issues about working at the infoset level
  - removing (expanding) entities
  - combining adjacent sequences of character infoitems
  - explicitly defining the used infoitems (and those with no mappings)

Which is based on how XPath does it, using a mapping to nodes:
  XPath - Appendix B: XML Information Set Mapping (Non-Normative)
I use some of the same words, but didn't want to introduce a
normative dependency on XPath 1.0 REC which puts in a non-normative
appendix, or on the draft XPath 2.0 / XQuery 2.0 WD, still in
development: http://www.w3.org/TR/query-datamodel/

Adding such a dependency might indicate that in order to implement
RDF/XML, you needed to understand and implement XPath, which isn't
the case.

This transformation to a sequence of events is meant to be familiar
to developers as directly mapping to the three SAX events that are
needed for implementing RDF/XML - start element, end element, and text.
This has had good feedback at being clear to developers.

  Note: It seems you are looking at the editors draft of the WD, since
  in the current published WD 'events' are called nodes.  However I
  have subsequently felt this was confusing since there are RDF graph
  nodes mentioned several times.  I have yet to add emphasis that the
  word 'event' isn't meant to imply anything else (and other words such
  as entity, item, object are also overloaded).

> Problems and Specific Comments:
> 1/ The rule for abbreviation of string-valued properties (Section 2) is not
>    correct, because of the XML requirement that attributes names be unique
>    within an XML element.

I assume you are refering to
  "When the property value is a string it can be encoded more simply
  as an XML attribute and value, as an attribute of the node
  element. This is known as a property attribute and shown in Example 4:"

and you are correct, I will fix this.

> 2/ How is base-uri set from the root node?  If this is part of the infoset
>    model, it should be mentioned.

The root (document) node is from document infoitem and it is there
that it defines base-uri:

  "5. [base URI] The base URI of the document entity."

and the Infoset REC in section 1 subsection "Base URIs"
makes a normative reference to XML Base which defines the method.

The syntax WD points this out in the definition of the root node:

In addition section 5.1 Grammar start describes how base-uri is
defined if RDF/XML is embedded in other XML.

> 3/ The semantic action for an empty subject on a nodeElement could be
>    executed even for element nodes with an rdf:ID or rdf:about attribute.
>    This is probably benign, but would cause the blank node identifier
>    generator to be pointlessly run, resulting in distinct (but
>    model-theory-equivalent) sets of n-triples resulting from a single
>    RDF/XML document.n

I don't follow you here; can you expand?

> 4/ The constraint on only one rdf:ID (or rdf:bagID) for a URI in a given
>    document is hidden deep in the document.  It would be much better to
>    gather all these context-sensitive constraints in one place.  It would
>    be even much better to remove these context-sensitive constraints, as
>    there is no need to have only one rdf:ID with a particular URI in a
>    document.  The development of this constraint is rather confusing, as
>    there have been statements to the effect that rdf:about="#foo" is a
>    synonym for rdf:ID="foo".

Linking and making these constraints more prominent is a good idea; I
will add this.

If I recall correctly, RDF Core decided that keeping them (for IDs)
was useful for users who could then rely on them, for example, when
defining RDF Schema RDF/XML documents, that the terms being defined
using rdf:ID were unique identifiers in that RDF/XML file.

It is true that the constraints don't apply when using rdf:about="#foo"
which I guess is seen more as referring rather than defining "foo"
despite these being equivalent; rather rdf:ID="foo" is equivalent
to rdf:about="#foo" but with the extra constraint.

> Comments on the Primer
> ...

> 3. An XML Syntax for RDF

This section is also similar to section 2 of the syntax WD, so some
comments here might need to be folded into the syntax WD; I'll also
comment here on syntax issues.

> It is not possible to use namespaces for the URI labels for object nodes,
> except (sometimes) for the labels of types.  In general, only edge labels
> can employ namespaces.  This is illustrated in the example RDF/XML syntax,
> which does not use namespaces for http://www.example.org/index.html.

(XML) Namespaces are only in the RDF/XML syntax and not in the RDF
graph.  The RDF graph uses URI-refs to label nodes, so graph edge labels
cannot "use (XML) namespaces"

I suspect you are getting at that in RDF/XML, XML qnames can only be
used to label the RDF graph URIs, and cannot be used to label graph
nodes?   If so I will try to fix in the syntax WD to make this clearer.

> The abbreviation example incorrectly states that rdf:resource is (always)
> used when ``the property value is another (existing) resource''.  There
> are, instead, lots of ways to do this in RDF/XML.

There are other ways, but this is a gentle introduction.  It can be
updated to note the other more verbose forms:

  <rdf:Description rdf:about="http://example.org/subject">
      <rdf:Description rdf:about="http://example.org/object"/>

  <http://example.org/subject> <http://example.org/prop> <http://example.org/object> .

Will fix (in syntax WD).

> This section retains the notion that rdf:about is used for existing
> resources and rdf:ID is used for new ones.  This is not correct.

Will fix (in syntax WD).

> The example for parseType="Resource" misleadingly implies that an rdf:ID
> attribute here would provide a name for the resource.  Instead an rdf:ID
> attribute here is a reification mechanism.

We have quite recently clarified this area, and indeed now rdf:ID on
properties always reifies so this needs fixing.


Thanks for the feedback

Received on Thursday, 30 May 2002 11:10:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:00 UTC