W3C home > Mailing lists > Public > www-rdf-comments@w3.org > October to December 1998

Subject: Re: Notes about RDF M&S draft of 8th October

From: Eric J. Miller <emiller@oclc.org>
Date: Wed, 25 Nov 1998 14:31:53 -0500
Message-Id: <365C5B28.5DB41EFD@oclc.org>
To: Olivier.Marce@inria.fr
Cc: www-rdf-comments@w3.org
Olivier,

Thank you for your detialed analysis and overall comments regarding
the RDF Model and Syntax specification.

The following is a response to comments reaised in your attached
message.

Comment 1:

We may have received a fragment of the entire RDF graph and thus
cannot tell whether the value given does not exist anywhere in the
entire graph. Any valid XML ID is also a valid relative URI, so the
first part of Olivier's heuristic is not effective.  Simply taking the
first instance of a name as the resource and subsequent instances as
further data about that resource would create other opportunities for
confusion and error.

Comment 2:

XML always specifies the default namespace (possibly through the
DOCTYPE). If the RDF engine cannot find a schema associated with the
namespace, then the property semantics simply remain unknown.

Comment 3:

We specifically included the phrase 'with respect to the resources
"foo" and "bar" ...' to indicate that there could be other differences
not elaborated here.  We considered your comment that the use of the
wording "is equivalent to" is misleading, however, after discussion we
felt that the prose in the specification was valid.

Comment 4:

For efficiency of queries, we decided not to allow regular expressions
(or other suggested ways of declaring collection membership) in this
version.  Thank you for suggesting alternative syntaxes.

Comment 5:

The model needs a uniform way to represent a statement as a
first-class resource.  Without this we would not be able to describe
relationships between statements.

Comment 6:

The Properties defined by the RDF Model and Syntax specification are
in fact described in RDF Schema form as, e.g.
http://www.w3.org/TR/WD-rdf-syntax#predicate.  This is the full unique
name of the property informally known as "the RDF predicate property".
The purpose of the '#' at the end of the namespace name is described
in the RDF Schema Specification. http://www.w3.org/TR/WD-rdf-schema

Comment 7:

Expansion of qualified names into absolute URIs is not defined
anywhere else, so it is within the scope of the RDF Syntax
specification to define this.  In fact, the full name of a property is
*not* its Generic Identifier but is the concatenation of its
corresponding namespace name with the LocalPart used in the Qname.  It
is fundamental to the RDF model that the full name of a property is a
URI.

Comment 8:

We do not expect to include other means of defining collection
membership in the first version of RDF.

Comment 9:

 It is true that we cannot anticipate the semantics of
future attributes whose names start with 'xml', but if we exclude them
from the model now we guarantee that no RDF-based
search/query/decision tool will be able to act on them.  Whereas, if
we (implicitly) allow such attributes to be represented as properties
then we have the possibility that some operations can be performed
even though the specific semantics are not represented in RDF.  As an
example, consider DOM version 1.  It knows nothing about namespaces.
But the 'xmlns:*' attributes are available for discovery through the
DOM APIs as normal attributes, so a namespace-aware application can
still be successfully built using DOM version 1.  As another example,
while we have a (presumably better) interpretation of xml:lang now, it
would not have harmed the basic model very much to have xml:lang be a
property.

We wish to allow (presently unknown) xml attributes to appear as
properties so that future applications that do know their semantics
might be able to be built on RDF version 1 without waiting for an
update to the RDF Model and Syntax specification.

Comment 10:

Please refer to the report [XMLinHTML] of a workshop we held in
February, 1998 to discuss the tradeoffs of various methods for
including XML in-line in HTML.  Given all the constraints and the
consequences of each alternative, we made what we thought were the
most pragmatic recommendations.

[XMLinHTML] http://www.w3.org/TR/NOTE-xh

Comment 11:

Good points.  We have chosen not to specify this in our initial
document while we examine the possibilities of extending WebDAV (etc.)
to use RDF metadata.


Sincerely,

Ralph Swick, W3C Metadata Activity Leader
Eric Miller, Bob Schloss, RDF Model and Syntax Chairs


> Date: Fri, 16 Oct 1998 12:10:08 +0200 (MET DST)
> From: Olivier MARCE <Olivier.Marce@inria.fr>
> Message-Id: <199810161010.MAA04764@aquarelle.inria.fr>
> To: www-rdf-comments@w3.org
> Cc: swick@w3.org, ora.lassila@research.nokia.com
> Subject: 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 Wednesday, 25 November 1998 14:32:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:26 GMT