W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2003

Primer LCC, review.

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Tue, 14 Jan 2003 16:55:48 +0000 (GMT)
To: RDFCore Working Group <w3c-rdfcore-wg@w3.org>
Message-ID: <Pine.GSO.4.44.0301141439070.28405-100000@mail.ilrt.bris.ac.uk>

A few trivial nitpicks. Appendix A actually anticipates the only issue I
have with this document (although it basically says, "there is an issue,
we don't deal with it").

1. Introduction

Figure 1 already includes the denotation/addressing issue I raised in
the schema review. Is it purely accidental that Eric Miller's mailbox
is named by a URI that also lets you address mail to him? I'd guess not.
What are the conventions governing the use of such "suggestive"
addressing names?

In other words, why does this figure have the following triple:

<http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#mailbox> <mailto:em@w3.org> .

and not this:

<http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#mailbox> _:a .
_:a rdf:type eg:Mailbox .
_:a rdfx:uri "mailto:em@w3.org"^^<xsd:uri> .

or this (or some variant?)

<http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#mailbox> "mailto:em@w3.org" .

[Come to think of it, why a mailto: and not an imap: url?]

Following on from the example:

"unlike conventional hypertext, RDF URIs can refer to any identifiable
thing, including things that may not be directly retrievable on the Web"

OK so far, but are there any distinguishing characteristics that can
tell one kind of URI from another?

(I note that this issue is addressed to some extent in Appendix A.)

2.1 Basic Concepts

The example is good, again, but has this: "In this statement, we've used
the Web page's URL (Uniform Resource Locator) to identify it."

OK, but how do I know that's what you've done? Is there some convention,
or some magic associated with the domain of the creator property?

In other words, there appears to be some restriction on valid
interpretations of this statement that's got something to do with the
URL labelling a resource being the address of a web page. I don't think
this is articulated anywhere. I won't belabour this point though.

Nitpick: "the object is the words..." should be "the object is the
phrase" (currently doesn't agree on number)

2.2 and onwards.

I like this. The document in general is an easy read, the pictures are
colourful and straight-forward, and there are lots of examples. The
narrative structure is good and the whole thing smacks of eloquence and
polish. A very nice job.

Namespace prefix definitions: there's an example which includes -

	ex:index.html dc:creator exstaff:85740 .

Again, this tacitly ignores the fact that ex:index.html appears to name
a web page, and exstaff:85740 appears to name a person; but they both
look like URLs to me. I don't hold the primer at fault here, because
this goes on a lot in RDF in the wild (it seems) - I'd be satisfied with
some way of telling which was which.

2.3, Figure 6 explanatory text:

This is not a bad stab at explaining the graph-specific identity of
blank nodes in a "see spot run" stylee :-) In addition, there follows
some excellent text about not using things that look like URLs to name
things that don't have URLs (eg, people). This is a really important
idea (blank nodes everywhere?) and it's introduced well. Hopefully it
won't get lost in passing.

In fact, it's worthwhile considering if this idea (obvious as it may
seem) isn't worth extracting into a separate note, because it's really,
really important, and Eric and Frank have done a good job of explaining

2.5. Concepts summary

Nitpick (numbering format change in heading)

4.1 RDF Containers

Example 14 and Figure 15 contains example1.org and example2.org domains:
are these reserved for example use? How about ftp1.example.org, etc?

4.4 rdf:value

I'm really uncertain whether rdf:value deserves the excellent treatment
here. It seems to me that other modelling approaches are more likely to
be successful in the long run (eg, factoring units into the property
definitions, so "exterms:weight" is defined as "weight in kilogrammes"),
although I'm ready to be set straight on that point (I've a sneaking
suspicion that there may be reasonable counterexamples in the iCalendar
world). I'd like at least to see an alternative mentioned (although
perhaps the primer isn't the place for this).

5.3 Interpreting RDF Schema Declarations

Another eloquent exposition of an important thesis. Last paragraph is
one of those that'd definitely have to be in one of those mythical
cut-down "views" of the primer text :-)

6.1 Dublin Core

The dc:subject is an rdf:Bag in the example. I'm _still_ not sure what
this means, particularly given the description of rdf containers
previously in the document (the prose related to the example in 4.1
concerning a rules committee would seem to imply that the rdf:Bag should
not have been used). I seem to recall discussing this around in circles
before now; I don't recall the conclusion.


"For example, dc:date is extended by properties like
prism:publicationTime, ..." Technically, isn't it restricted or
constrained, not extended? Maybe "speciali[sz]ed"?

Appendix A.

"People sometimes use RDF together with a convention that, when a URIref
is used to identify an RDF resource, a page containing descriptive
information about that resource will be placed on the web "at" that
URI...However, this convention is not an explicit part of the definition
of RDF, and RDF itself does not assume that a URIref identifies
something that can be retrieved."

Fair enough, and perhaps this is all the RDF specs need to say on the
subject, but since there's a "Web" in "the Semantic Web" I'd hope that
someone, somewhere, is going to say more about this (TAG?).


I really like this. It's quite a dense document and I'll be reading it
again to see if there's anything I've missed (third time lucky?);
thumbs-up to publish.

jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
Goth isn't dead, it's just lying very still and sucking its cheeks in.
Received on Tuesday, 14 January 2003 11:57:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:19 UTC