re: RDF Core working drafts

From: Peter F. Patel-Schneider (
Date: 05/16/02

  • Next message: Benjamin Grosof: "short paper on DAML-Rules as background for tomorrow's Joint Committee telecon"
    From: Dan Connolly <>
    Subject: re: RDF Core working drafts
    Date: 15 May 2002 16:46:25 -0500
    > > 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.
    > I don't think I understand this; maybe an example would help?
    Suppose you have
      <foo rdf:ID="bar" />
    It is permitted to run the blank node identifier generator when processing
    this description because the semantic action for this can be performed
    before the semantic action that sets e.subject from rdf:ID.
    > > The theory of literals in the model theory is very weak.  This means that
    > > there is no relationship whatsoever between literals the differ only on
    > > their language (or on the presence of a language).
    > Hmm... I don't see why it would/should be otherwise.
    Users may have different expectations, so there should be a clear statement
    that this is the case.
    > > 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.
    > > 
    > > This section retains the notion that rdf:about is used for existing
    > > resources and rdf:ID is used for new ones.  This is no longer correct,
    > How so?
    There is no need to use rdf:ID.  It is possible to have an rdf:about for a
    resource before any rdf:ID for that resource.  
    > Are you referring to this text?
    >   So far, we've been describing resources that have been defined (and
    >   given URIs) already. For instance, in our initial examples, we've been
    >   providing descriptive information about's web page,
    >   whose URI was We referred to this
    >   resource (defined elsewhere) using an rdf:about  attribute. However,
    >   obviously we also want to be able to define new resources. For
    >   example, suppose a company,, wanted to provide an
    >   RDF-based catalog of its products as an RDF/XML document,
    >   identified by
    >   Within that resource, each product might be given a separate
    >   RDF description. An example of one of these descriptions (the
    >   catalog entry for a tent) might be:
    > 1.   <?xml version="1.0"?>
    > 2.   <rdf:RDF xmlns:rdf=""
    > 3.               xmlns:ex="">
    > [...]
    > I don't see anything incorrect there. rdf:ID can still be used that
    > way.
    Yes, but the indication here is that rdf:ID is the only way to define new
    resources, which is certainly not the case.n
    > > nor
    > > is it the case that there must be at most one rdf:ID for a given URI in a
    > > document.  
    > Yes, it is the case.
    > "Constraint: The names used as values of rdf:ID and rdf:bagID attributes
    > must be unique in a single RDF/XML document..."
    What does the statement from the chair
    that states that rdf:ID="foo" is a synonym for rdf:about="#foo" mean then?
    I think that a reconcilliation between these two incompatible points of
    view is needed.
    The limitation to ``within a single RDF/XML document'' is rather strange.
    If I can have 
    Doc 1:  rdf:ID="http:x"
    Doc 2:  rdf:ID="http:x"
    why can't I have
    Doc 1:  rdf:ID="http:x"
    > > The example for parseType="Resource" misleadingly implies that an rdf:ID
    > > attribute here would provide a name for the resource.  Instead an rdf:ID
    > > here is a reification mechanism.
    > Which example? I don't see the problem.
    Two paragraphs after Figure 8 there is a strong indication that rdf:ID with
    parsetype=resource will give the resource an ID.  This is not the case.
    > > 4. Defining RDF Vocabularies: RDF Schema
    > > 
    > > This section give the impression that RDF Schema is nothing more than a
    > > well-known set of names, to be used in RDF.  Instead RDF Schema is a
    > > semantic extension to RDF.
    > It says that the well-knonwn names don't have
    > related well-known meaning/semantics/axioms?
    > Where?
    There is no indication that such is needed in RDF Schema.  Readers may get
    the impression that RDF Schema is given meaning by an RDF document, nothing
    > >  This section blurs the distinction between RDF
    > > and RDF Schema, particularly in its treatment of rdf:type.
    > Hmm... I haven't read it closely enough to know what you mean by that,
    > I guess.
    The impression there is that rdf:type is given a meaning by RDF Schema.
    However, all that RDF Schema does is gather resources that are RDF types
    into a grouping called rdfs:Class.
    > > Overall comments:
    > > 
    > > The lack of any treatment of datatyping in RDF (except for a few mentions
    > > that state that datatyping is deferred to the future) is surprising, and
    > > disappointing, particularly in light of the mention of XML Schema datatypes
    > > in the RDF Core WG charter.
    > Yes, it's frustrating that we didn't get a datatyping WD out.
    > -- 
    > Dan Connolly, W3C

    This archive was generated by hypermail 2.1.4 : 05/16/02 EDT