- From: Ben Adida <ben@adida.net>
- Date: Mon, 11 Aug 2008 15:52:24 -0700
- To: "Ralph R. Swick" <swick@w3.org>
- CC: public-rdf-in-xhtml-tf@w3.org
Ralph,
I'm top-posting because.... +1 to everything, I have nothing to add,
this is a great and complete response, including the recommendations you
propose to the text.
Mark, Shane: what do you think? If you agree, can we update the editors'
draft accordingly ASAP? The changes should be minimal.
-Ben
Ralph R. Swick wrote:
> 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 Monday, 11 August 2008 22:53:06 UTC