- From: Ralph R. Swick <swick@w3.org>
- Date: Fri, 08 Aug 2008 16:23:46 -0400
- To: public-rdf-in-xhtml-tf@w3.org
At 10:06 PM 7/9/2008 +0000, SWD Issue Tracker wrote:
>ISSUE-122: CR Comment: Comments on Syntax from Alan Ruttenberg
>
>http://www.w3.org/2006/07/SWD/track/issues/122
>
>Raised by: Ben Adida
>On product: RDFa
>
>Alan Ruttenberg sent comments in [1].
[1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Jun/0080.html
ACTION: Ralph to work with Ben on proposing specific editorial changes to RDFa Syntax document based on ISSUE-122. [recorded in http://www.w3.org/2008/07/31-rdfa-minutes.html#action23]
Here are my proposals for editorial changes and responses to
Alan's comments. Alan raises some helpful points, not all of
which I believe need to be reflected in changes to the document.
(These have not yet had the benefit of Ben's input; sorry -- I've
started this several times since last Thursday and each time
I've been interrupted.)
At 04:26 AM 6/13/2008 -0400, Alan Ruttenberg wrote:
...
>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. I looked through
the FOAF vocabulary for a simple alternative that would require the
least surgery on the example. I propose that we repair the example
by using a different property and asking Mark to coin a URI naming
his company:
replace
<link rel="foaf:workplaceHomepage" href="http://www.formsPlayer.com/" />
with
<link rel="foaf:topic" href="http://www.formsPlayer.com/#us" />
We don't need to go into any details about how (and why)
... /#us names a non-information-resource.
>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 I 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 IMHO 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.
Is this good practice? I dunno. 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. I'll 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 me 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."
> 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 could either make the SPANs empty or expand 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 would clarify 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.
It might be less confusing for that sentence in section 2.1 to say
"... associate with a subject" and to make the same change to
the description of @about and @property. The @datatype
description in that section uses this 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.
>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. Perhaps it would eliminate this small concern
if the sentence in section 6 were to include a parenthetical
"@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)."
My/our feeling is that this parenthetical might increase rather
than decrease confusion.
>--
>
>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 answer should be -- I believe -- that the current object literal
is the empty string. This would be 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.
The 3rd sub-bullet of the [plain literal] case should 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.
Perhaps the section titles might be better descriptive as
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
(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 of draft response]
Received on Friday, 8 August 2008 20:24:42 UTC