- From: Ralph R. Swick <swick@w3.org>
- Date: Thu, 14 Aug 2008 15:18:12 -0400
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: public-rdf-in-xhtml-tf@w3.org
At 04:26 AM 6/13/2008 -0400, Alan Ruttenberg wrote:
>Find below my review of this CR. It is possible that I have
>misunderstood elements of the specification, in which case I would be
>grateful for corrections. Please note that this is not an exhaustive
>review, but rather a selection of items that caught my attention.
Thank you for these comments, Alan. We recorded this
as ISSUE-122 [1] in the Semantic Web Deployment Working
Group issue database.
[1] http://www.w3.org/2006/07/SWD/track/issues/122
The response from the RDF-in-XHTML Task Force to each of
your points follows. We hope this response is satisfactory to
you and look forward to your confirmation.
>--
>
>In section 2.2, the examples of syntax, the interaction between the
>domain of properties and the parent subject is confusing. Specifically:
>
><html
> xmlns="http://www.w3.org/1999/xhtml"
> xmlns:foaf="http://xmlns.com/foaf/0.1/"
> xmlns:dc="http://purl.org/dc/elements/1.1/"
> >
> <head>
> <title>My home-page</title>
> <meta property="dc:creator" content="Mark Birbeck" />
> <link rel="foaf:workplaceHomepage" href="http://
>www.formsPlayer.com/" />
> </head>
> <body>...</body>
></html>
>
>Here we have
>
><> dc:creator "Mark Birbeck"
><> foaf:workplaceHomepage <http://www.formsPlayer.com/>
>
>The domain of foaf:workplaceHomepage is a foaf:Person. The first
>statement says that <> is a foaf:Person. The second statement says
>that that person is created by Mark Birbeck. The Title suggests that
><> is a web page ("My home-page").
Indeed, this example misuses the FOAF vocabulary. We have
adopted a simple repair to the example using a different FOAF property:
replace
<link rel="foaf:workplaceHomepage" href="http://www.formsPlayer.com/" />
with
<link rel="foaf:topic" href="http://www.formsPlayer.com/#us" />
>In the following example we have a similar situation. The title
>suggests that the URI denotes a blog. However, the domain of
>cal:summary is UnionOf(Vevent Vtodo Vjournal Valarm). While <> might
>conceivable denote a an instance of Vjournal, the title suggests that
><> is the blog, rather than a specific entry in the blog.
This is all true but we do not see that it does any great violence to
the ical vocabulary. It's a question of Best Practice for use of
that vocabulary, for which we may not have enough precedent.
The fact that the HTML title "suggests" a Class for the document
does not in our opinion critically detract from the point the example is
meant to illustrate.
> However,
>the intent seems to be that the subject is a Vevent (as indicated by
>a later example using <p typeof="cal:Vevent">, and the subject seems
>to be simply absent.
The subject is not absent -- it is the initial [parent subject] per
Section 5.2; i.e. the current document. The later example
says explicitly that the current document has type cal:Vevent.
We do not claim to know whether or not this good practice.
It doesn't seem to be explicitly contradictory, unlike the FOAF case.
>(I separately note that the http://www.w3.org/
>2002/12/cal/ical# has harmless, but perhaps confusing, duplicate
>elements in the domain of cal:summary and other properties)
Indeed. We will try to find out who thinks they're the maintainer of
that namespace now. The N3 and RDF/XML files appear to
have been machine-generated from something else.
><html
> xmlns="http://www.w3.org/1999/xhtml"
> xmlns:cal="http://www.w3.org/2002/12/cal/ical#"
> >
> <head><title>Jo's Friends and Family Blog</title></head>
> <body>
> <p>
> I'm holding
> <span property="cal:summary">
> one last summer Barbecue
> </span>,
> on September 16th at 4pm.
> </p>
> </body>
></html>
>
>The subsequent example, with
> <span property="cal:dtstart" content="20070916T1600-0500"
> datatype="xsd:datetime">
> September 16th at 4pm
> </span>.
>has the same issue.
The domain of cal:dtstart is not identical to the domain of
cal:summary but it does include cal:Vevents and continuing
to conflate documents and cal:Vevents seems relatively
harmless to us for now.
>The example using typeof either explicitly states the subject is a
>Vevent (However, see below comments re:typeof - Is this the type of
>the document? or is the subject a new blank node?) .
@typeof introduces a new (in this case, blank) node per step 4
in section 5.5. This new node is the subject of the rdf:type triple.
> This clashes,
>then, with the title.
Due to the changed subject, the title prose mismatch doesn't
occur in this case. The prose mismatch could be said to exist
in the previous example but again doesn't seem harmful.
> Strictly speaking, it is also redundant, given
>that this can be inferred from the domain of cal:summary.
Technically the node could be a Vjournal (and others) as well,
but again that is orthogonal to the point of the example. It is
fine for an author to not assume that all tools support RDFS
inferencing.
> Perhaps the
>remedy is to change the title to make it clear that the subject is a
>Vevent. *OR* it emphasizes the fact that the previous subjects have
>no subject.
We feel it is more appropriate to indicate to authors the minimal
markup they might wish to add to expose the explicit semantics
of their current pages. Suggesting that titles should also be
changed could introduce more confusion rather than less.
>Some explanation of how the use of html to represent a Vevent is to
>be understood as compared to a situation of content negotiation,
>where a document of mime type text/calendar might also be expected to
>be available at the same URI, making it perhaps more clear that the
>URI must denote a calendar event.
Interesting point. AWWW would say that the two representations
need to contain the same information content. That whole
discussion would be out of scope for this specification. We're
targeting HTML authors so discussion of other MIME types and
content negotiation is not likely to reduce confusion in this audience.
>The next example says "The metadata features available in XHTML only
>allow information to be expressed about the document itself. RDFa
>provides a means of referring to other documents and resources"
>
> <span about="urn:ISBN:1596913614" typeof="biblio:book">
> autobiography
></span>.
>
>Here there is a question of what "referring" to means. What refers to
>what?
Nice catch. The sentence means to say "RDFa allows the document
to contain metadata information about other documents and resources."
We have modified the sentence accordingly.
> Should we not have a triple of the sort:
><> referes_to <....> if reference is intended?
The sentence was not intending to express a formal relationship.
> What makes the about
>here different from an href? Is there a missing @property here?
@about is only naming a new subject. @href would be used
when there is a desire to create a hypertext link as well as
naming the object of a triple. This example does not specify
any connection between the document and the two biblio:books.
>In addition, the directedness of the <span> element seems to me to
>further confuse matters. Consider two common cases of the use of
><span> in html - to <span class="foo">element</span> or <span
>style="font-size:20">element</span>
>
>In these cases the relationship is such that the span says something
>about element - the style or the class - element is the object of an
>implicit statement. However, in the case of autobiography,
>"autobiography" is either a label of urn:ISBN:1596913614, or
>"autobiography" refers to urn:ISBN:1596913614.
Reasonable point. There is no semantic information provided
by the SPANs in this example, (unlike the ical examples where
@property does then use the text content of the SPAN).
We have expanded the example to
I think White's book
'<span about="urn:ISBN:0091808189" typeof="biblio:book"
property="dcterms:title">
Canteen Cuisine
</span>'
is well worth getting since although it's quite advanced stuff, he
makes it pretty easy to follow. You might also like
<span about="urn:ISBN:1596913614" typeof="biblio:book"
property="dc:description">
White's autobiography
</span>.
>So we have a situation in which no clear reference (as manifested as
>a triple) is present, and yet in which "autobiography" seems possible
>to be both the subject and object of some reference.
The expanded example above clarifies that the text content of the
span is the object of some triple. But the basic misperception
here is that the specific choice of the SPAN element identifier carries
RDFa semantics, which it does not.
>A later example, which has no text is enclosed by the span, seems to
>deny either case.
>
><div about="http://dbpedia.org/resource/Albert_Einstein"
>rel="dbp:citizenship">
> <span about="http://dbpedia.org/resource/Germany" />
> <span about="http://dbpedia.org/resource/United_States" />
></div>
Correct; your notion of the HTML 'directedness' of SPAN is
orthogonal to RDFa, as SPAN itself has no RDFa semantics.
>--
>
>The documentation of typeof is confusing. First we have:
>
>@typeof a whitespace separated list of CURIEs that indicate the RDF
>type(s) to associate with the subject
>
>This suggests that typeof simply adds information about an existing
>subject.
We have changed that sentence in section 2.1 to say
"... associate with a subject" and have made the same change to
the description of @about and @property. The @datatype
description in that section uses this same pattern.
>However later:
>
>@typeof is unique in that it sets both a predicate and an object at
>the same time.
The full context of that sentence in section 6 shows that the point
being made is that the other attributes establish just one field of
a triple whereas @typeof is setting two fields in a triple. This
sentence is not in contradiction with section 2.1 or section 5.5.
We have modified this sentence, however; more below.
>And , in the processing section we have
>
>if @typeof is present, obtained according to the section on CURIE and
>URI Processing, then [new subject] is set to be a newly created [bnode];
>
>In this case the typeof seems to create a *new* subject (the blank node)
Correct. This sentence in the 6th bullet of processing rule 4
applies to the specific case of establishing a [new subject]
when none of @about, @src, @resource, or @href are present.
One could say that in this case @typeof is setting all 3 fields
of the triple. To reduce this small concern we have added to
the sentence in section 6 a parenthetical note:
"@typeof is unique in that it sets both a predicate and an
object at the same time (and also a subject when it appears
in the absence of other attributes that would set a subject)."
>--
>
>Step 9 "The next step of the iteration is to establish any [current
>object literal];"
>
>In the case that "or there are no child nodes", what plain literal is
>the current object literal? ""?
Nice catch. An example would be:
<span about="urn:ISBN:0091808189" typeof="biblio:book"
property="dc:title" />
The intent is that the current object literal is the empty string.
This is consistent with the final sentence of the [plain literal]
case of step 9: "... a string created by concatenating the text
content of each of the descendant elements ..." but should
be explicit as there are no descendants in this instance.
We have changed the 3rd sub-bullet of the [plain literal] case
to read:
"* or there are no child nodes (in which case the literal value is
the empty string)"
>--
>
>6.1.1.5.2. Using an implicit object
>
>I am confused about which processing model is normative. It would
>seem that these rules should be considered part of "Completing
>'incomplete triples' " or better, in the processing model.
This section does follow from steps 5, 8, and 9 of section 5.5.
Chapter 6 is normative but is not intended to have any constraints
that are not specified in section 5.5.
> Moreover
>this section is consider a subsection of the section called 6.1.1.5.
>Inheriting a subject.
Section 6.1.1.5. is talking about ways that a subject can be
determined when one has not been set explicitly; i.e. neither
@about nor @typeof are present. You are correct that this
repeats patterns that appear in section 6.2 but 6.2 discusses
other situations as well and is already a long section.
We have changed the section titles to be better descriptive:
6.1.1.5. Determining the subject with neither @about nor @typeof
6.1.1.5.1. Inheriting subject from @resource
6.1.1.5.2. Inheriting an anonymous subject
(We note that it would be less confusing to RDF folk to use "blank"
instead of "anonymous" but that term of art won't help the HTML
audience.)
> Or why not under 6.3 (Object resolution).
6.1.1.5.2. is as much talking about subjects as it is about
objects. You're right that it could justifiably appear in a different
order. That would not change the meaning.
>It
>was not clear to me whether this case (and some others) were even
>covered in the processing model. In this case the question is: what
>exactly is meant by "processing model"?
The cases are covered in section 5.5, steps 5, 8, and 9.
>Generally I would prefer to see one section (5) be considered
>normative and complete, and other sections (6 in particular) be
>informative. Otherwise the reader is confused about how to thread
>together a processing model out of the various pieces that are offered.
Section 5.5 and 6 should not be in conflict. If a real conflict is
uncovered then we want to fix the conflict rather than bury it
under a "non-normative" cover.
>I should say that I am confused about how to know when <div>
>introduces a new blank node, and when it doesn't.
DIV does not by itself introduce bnodes; more generally, DIV
has no unique RDFa semantics. It is the presence of other
attributes, usually @rel and @rev or @typeof that introduce
bnodes.
We hope this has clarified the specification for you.
>--
>
>Section 7 Curie Syntax Definition.
>
>Why do we have a normative section on CURIES in this document rather
>than a reference to http://www.w3.org/TR/curie/ ?
Purely a matter of timing. The RDFa design is complete and
is a use case for CURIEs. The standalone CURIE specification
is for the benefit of other modules that want a solution to the
same problem of overloading the QName functions. Because
RDFa is further along we do not want to hold up its deployment
while waiting for the standalone CURIE document to complete
review. The intention is that a future edition of the RDFa
specification would cite a standalone CURIE specification
when and if one is approved.
>Having duplicate normative sections in different documents is a
>recipe for confusion and a magnet for desynchronization.
The editors of both documents are the same and have
committed to minimizing loss of synchronization.
>---
>
>Section 9.3. @rel/@rev attribute values
>
>Why do we have a normative section here rather than referring to
>http://www.w3.org/TR/xhtml-modularization/
This, too, is a matter of timing. It was the choice of the XHTML2
Working Group to put the normative list into this document
rather than further delay RDFa deployment.
[end]
Received on Thursday, 14 August 2008 19:21:45 UTC