Re: Primer LCC, review.

Jan--

Thanks for the comments.  More detailed responses below.

--Frank

Jan Grant wrote:
> 
> 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?]

This example originated with Eric if I remember correctly, so perhaps he
was doing some real subtle stuff that I'm not picking up on in the
following.  But the short answer is that, although I think you have an
important issue (or issues) here, we're not trying to get at it (them)
yet.  After all, we're only three paragraphs into the real Primer text
here.  More specifically:

a.  a mailto: URI is the first thing I would think of when called on to
identify a mailbox, which is what we're doing
b.  it nicely gives us an early example where a URI is a statement's
object (although we unfortunately don't build on this example as much as
we might have, something Brian pointed out earlier)
c.  we don't use the blank node thingie because (i) it would make the
graph more complicated, for a reason I don't think we're prepared to get
into at this point, and (ii) I don't want to show a graph at this point
with an unlabelled node (labeled graphs are new enough at this point,
people might think it was a typo, and we don't get to blank nodes until
much further along).
   
> 
> 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?

As far as I know, there aren't any such distinguishing characteristics,
and I frankly think that's a good thing.

> 
> (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?

Could you clarify?  As far as I can see, you know that's what I've done
because I've just told you.  I don't expect you to have to infer
anything from the creator property.  Remember, we started off with the
sentence "Imagine that we want to state the fact that someone named John
Smith created a particular Web page."  It seems to me that the URL of
the page is the obvious way to refer to it, I used the URL in the
statement, and then I pointed out that I did that.  One thing I'm trying
to do here is gradually introduce the idea of URIs being used to
identify things in RDF, and the obvious starting point is for the things
being identified to be Web pages, where it's hard to imagine anything
*but* URIs being used to identify them.

> 
> 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.

I didn't have anything like this in mind in that example.
> 
> Nitpick: "the object is the words..." should be "the object is the
> phrase" (currently doesn't agree on number)

I can see that the number doesn't agree;  it didn't occur to me that
"John Smith" was technically a phrase.  But I'll do something about
this.

> 
> 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.

I don't know that I agree about telling which was which, but that's a
deeper issue than we need to go into right now.  Anyway, as you say,
there's a lot of existing RDF that does this sort of thing.

> 
> 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
> it.
> 
> 2.5. Concepts summary
> 
> Nitpick (numbering format change in heading)

Do you mean that this one has a period after the number and other ones
don't?  If so, that inconsistency appears in other places too.  I'll
clean this up.

> 
> 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?

No reservation that I know of.  I'll fix this.
 
> 
> 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).

There are certainly other approaches (one I suggested was to have
different data types for the weight in different units, but there were
objections to that).  I think we've beaten rdf:value to death;  we could
certainly have a longer discussion of why it's there, and alternatives
to using it, but I think writing that discussion would unnecessarily
delay things.

> 
> 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.

Actually, I think the DC example is more like the "publications" example
in 4.1 than the rules committee example.  In the publication case, the
question is whether it is accurate to say that someone published a group
of things, rather than each individual thing separately.  Here, the
question is whether it is accurate to say that the subject of the web
page is a group (of individual subject descriptors), rather than each
subject separately.  I'm not sure I want to discuss this any further in
the Primer, certainly not right now.  I will say that this sort of thing
raises some questions about its impact on using RDF in data integration
applications where a fully normalized structure is important, and a
vanilla RDF app, not knowing that something like "subject" should
distribute over the members of the Bag, doesn't recognize common
structures when it should.  

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

I think it might be more accurate to say something like "more precise
variants of dc:date are provided by properties like ...".  I wouldn't
want to say restricted, constrained, or specialized, unless I knew there
was a subProperty relationship actually defined (I'd need to check the
PRISM spec).

> 
> 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?).

Hopefully the TAG.  After all, we can say whatever we want, but it only
has normative effect in RDF (and not even that if it's only said in the
Primer!).

Thanks again,

--Frank


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752

Received on Tuesday, 14 January 2003 13:47:44 UTC