Re: [ALL] RDF/A Primer for review - Response to Gary Ng's Comments

Ben,

Areyou in a position to propose the draft for WG publication?

Best,
Guus


Ben Adida wrote:
> 
> 
> Gary,
> 
> Thanks very much for your comments.
> 
> Please find the task force's responses below. Note that the responses  
> from Section 1 (Overall Organization) are from me alone, while the  
> responses to Section 2 (Design of RDF/A itself) are the result of  task 
> force discussions from this week's telecon. We did not have time  to 
> cover Section 1 in our telecon, so, as the primary author of the  
> Primer, I take it upon myself to answer those organizational  questions. 
> The conceptual questions were discussed with everyone.
> 
> 
>> It is a nice piece of work with clear intentions and examples. The
>> principle of not duplicating content and embedding RDF content in a  way
>> browsers can extract is clearly articulated. The proposal with
>> individual examples surrounding the photos and camera use case, plus
>> showing their RDF equivalent is very informative.
> 
> 
> Thanks!
> 
>> 1) Overall Organization
>> =======================
>>
>> Would it be beneficial for the reader to have some brief  introduction on
>> basic constructs, before diving into how they are used in the use  case?
>> I found it difficult to follow the examples without first have an
>> overview understanding of (or knowing the boundary surrounding...) the
>> number of ways in which RDF can be specified, and using which
>> constructs.
>>
>> For example, mid way through the doc, I found myself asking the
>> question:
>>
>>     - "How about annotating tables, frames, forms and dynamic content
>> from scripts producing menus and flash?"
>>
>>     - "How do I create chains of triples?" For example, an address  of a
>> person (Mark in the example), represented by an annoymous node,  which in
>> turn has statements specifying triples making up the address.
>>
>> These were answered after checking the RDF/A Syntax [1]. In fact, the
>> primer could effortlessly include these concepts only with a little
>> introduction to the constructs.
> 
> 
> 
> We wrestled with this a bit, and we chose to keep the RDF/A Primer  
> short and example-focused, leaving the syntax description to the RDF/ A 
> Syntax Document. The RDF/A Primer is definitely not meant to be  
> complete, but rather to give a taste of what RDF/A can do for you. If  
> the Primer raised questions that led you to the syntax document, then  
> that is a successful Primer, in my opinion.
> 
> Mark Birbeck is working on a set of even simpler examples to target  the 
> blogging community. These would help introduce simple metadata  for HTML 
> authors, before we even bring in RDF triples. I'll talk more  about this 
> at Monday's telecon.
> 
>> 1.1) In the preliminaries, the following sentence may provide some
>> initial context to the reader.
>>
>>      "An XHTML document marked up with RDF/A constructs is a valid  XHTML
>> Document. RDF/A is about using XHTML compatible constructs and
>> extensions to specify RDF 'content'. It is not about embedding RDF
>> syntax into XHTML documents."
> 
> 
> Good suggestion.  We'll work this into the Primer.
> 
>> 1.2) With regards to the above questions I had while reading, I  suggest
>> a small section right up front to introduce the basics, possible with
>> some simple examples from Section 3:
>>
>>      "id" and "about" - These are equivalent to rdf:id and rdf:about.
>> They can appear as xml attributes in any XHTML constructs,  including UL,
>> LI, DIV, BLOCKQUOTES, P ... etc. They essentially declare a rdf  subject
>> for constructing RDF/A statements, either locally within one document,
>> or made reference-able from other documents in the case of "id".
>>
>>      "link" and "meta" - These are the main constructs to create rdf/a
>> statements. Link is used to create a relationship to another URI
>> resource, whereas meta is used to attach literal properties. These
>> constructs can specify its own subject using "about", or they take the
>> immediate parent XHTML element's "about" as subject. In the case where
>> the immediate parent does not have qualifying URI, the subject is an
>> anonymous rdf node. In the case where the immediate parent is a
>> link/meta element without an "about" URI, this statement reifies the
>> parent statement.
>>
>>      "anchor" and "span" - These are alternative constructs to create
>> rdf/a statements. While anchor can be used instead of link, span  can be
>> used instead of meta. Their difference to link and meta is that anchor
>> and span applies to an 'inherited' rdf subject. The nesting  inheritance
>> is identical to how xmlns attribute is inherited within an XML  document.
>> If the nesting chain does not contain a qualified subject, the  document
>> itself is the subject. These constructs allow the RDF content to
>> somewhat follow the presentation of the content and thus avoid
>> duplication.
>>
>>      Both meta and span each have two ways of specifying the  associating
>> literal value. One is reusing what would also be displayed (the CDData
>> of the element):
>>
>>      <[span|meta] property="dc:date" type="xsd:date">2006-01-02</span>
>>
>>      The alternative is to use the 'content' attribute, where the  value
>> is not the the CDData and thus it is not displayed as well as being
>> different to the CDData.
>>
>>      <[span|meta] property="dc:date" type="xsd:date"
>> content="2006-01-02">XYZ</span>
>>
>>      In the latter case, if there is no CDData to display, this
>> effectively attaches a piece of RDF that does not have any  presentation
>> consequence. This symmetry is also observed with link and anchor.
> 
> 
> This is very useful text, but it seems much more appropriate for the  
> RDF/A Syntax document. The Primer's role is really to introduce RDF/A  
> to an HTML audience that isn't expected to know much about RDF in the  
> first place. Jumping into a description of all the RDF concepts up  
> front seems a bit much for a Primer.
> 
> Again, I do think this is useful for the Syntax document, though.
> 
>> 1.3 Perhaps the primer should be arranged with a target reader in  mind.
>> For example, to arrange from the point of view of an HTML author  wanting
>> to find out how to add annotations to his/her docs, in the quickest  time
>> possible.
>>
>> Primer How-to:
>>
>> A) say something about the Doc itself -
>>
>>   => essentially already in the examples within Section 3.
>>   . examples on link and meta,
>>   . examples on span and anchor,
>>
>> B) declaring individual elements contained in a doc, and say something
>> about them:
>>
>>   . Adding an id, currently embedded within section 4.3
>>   . The use of about, currently embedded within section 4.2
>>   . Then the usual way like above (A) to add metadata.
>>   . Refering back to an id within the same doc.
>>   . Refering an id in a different doc.
>>
>> C) say something about external content that the author has no control
>> over
>>
>>   => Currently 4.1
>>   . Annotating href links,
>>   . Annotating opague objects: images, scripts, objects
>>
>> D) Advanced Metadata
>>
>>   . using "link" and "meta" with unqualified XHTML elements, creating
>> chains of triples.
> 
> 
> Yes, this is exactly what we're trying to do with the added examples  
> that Mark is developing. The only difference is that we're going to  
> stay away from talking too much about RDF graphs, and rather gently  
> guide the HTML author from adding simple properties to adding more  
> complex RDF statements.
> 
>> 1.4 Section 4.3 Qualifying chunks of document.
>>
>>      The title doesn't quite match the content here. The content is
>> about how to declare elements and metadata (of individual cameras  on one
>> page) for other documents (photo album pages) to reference using  ids. It
>> is still talking about annotating individual items (Cameras) in the
>> document, and not chunks of document as a whole.
> 
> 
> A good point. Again, I wonder how much HTML authors will really  
> differentiate here, but the language should be clear nevertheless.  I'll 
> work on this.
> 
> 
>> 2) RDF/A itself.
>> =============================
>>
>> I must say at first glance I found the approach extremely  confusing. RDF
>> Mark up mixed with presentation markup such as <H1  property="dc:title">.
>> But I appreciate that there aren't that many choices to avoid
>> duplication of content, and to allow RDF markup within an orthogonal
>> presentation structure.
> 
> 
> Yes, there is bound to be some confusion at first. We're certainly  
> trying to minimize it - thus the limited scope of this primer.  
> Hopefully, by the time you finished reading the document, you were  less 
> confused. But let us know if there are additional things we can  do 
> (beyond your comments here) to reduce this confusion.
> 
>> 2.1) Synchronization issue between metadata on a doc, versus the
>> metadata contained within that doc itself.
>>
>>     Images, files and other media will have their own metadata  embedded
>> in the future. Certainly another html document will have its own
>> metadata. If RDF/A allows metadata to be added locally about a remote
>> URL, potentially the local metadata could be out of sync, or worse
>> contradict the metadata embedded within the resource itself?
> 
> 
> This is indeed an issue of concern, though it appears to be one that  
> applies to all RDF serializations, including RDF/XML. Methods for  
> resolving such inconsistencies should be devised at a general RDF level.
> 
>> 2.2) Consistency
>>
>>      I suspect there may already be an answer to this: Why are we not
>> using rdf prefixed attributes for RDF/A elements/attributes? rdf:id?
>> rdf:about? rdf:property, rdf:resource, rdf:description? This  relates to
>> Pat's [2] comments about future migration from RDF to XHTML too.
> 
> 
> The most important point here is that the task force tried hard to  use 
> RDF/XML syntax for RDF/A, but this failed because of RDF/XML's  striped 
> syntax. Note also that reusing existing HTML attributes turns  out to 
> make for a very good migration path for HTML authors (who  constitute 
> the main target of this work.)
> 
> As per our response to Pat's comments, the right way to migrate large  
> chunks of RDF/XML into HTML is to use a <link rel="meta"> element.  The 
> hard part of the migration requires determining which rendered  data 
> corresponds to which RDF property, and no amount of syntax can  help 
> there: it's a semantic merging operation.
> 
>> 2.3)  How about inheriting metadata through nested elements?
>>
>> > In [2] Pat Hayes wrote:
>> >
>> > Also, giving an id to a whole RDF (sub)graph fits naturally
>> > with the 'named graph' idea, unlike giving an id to every triple.
>> >
>>
>> This is interesting and would qualify as "Qualifying chunks of
>> document". For example, using some special non-presentational XHTML
>> elements to "group" metadata together?
> 
> 
> There may be a misunderstanding here. There *is* nesting in RDF/A:  you 
> can inherit the about attribute as far up/down the DOM hierarchy  as 
> you'd like. Is that what you're after?
> 
>> 2.4) The <img> element not allowing child elements makes the whole  RDF/A
>> approach rather uneven. Is <img> the only XHTML element that does not
>> allow child element? could XHTML2 be changed to allow these meta  data to
>> be the solely allowed child elements?
>>
>>     <li> <img src="/user/markb/photo/23456" />,
>>       <span about="/user/markb/photo/23456" property="dc:title">
>>         Sunset in Nice
>>       </span>
>>     </li>
>>
>>     Why don't we use the same approach instead of using <span>?
>>
>>     <img src="/user/markb/photo/23456" property="dc:title">
>>       Sunset in Nice
>>     </img>
>>
>>     of ocurse this now the subject is src="". But we can still make  this
>> work to say for img, the "about" is the "src" attribute. See 2.5  below.
> 
> 
> This turns out to be one of our outstanding issues that we are still  
> finalizing. [1]
> 
> We are currently leaning towards the syntax you mention, where the  
> content of an image element could include metadata about that image  and 
> the SRC attribute would be the subject. Steven is checking with  the 
> XHTML working group to ensure that this does not cause any  unforeseen 
> complications. However, what's important to note is that,  even if this 
> syntax is adopted, the "Sunset in Nice" text in your  above example 
> would only be rendered in a browser if there is a  failure to load the 
> image.
> 
> This seems consistent with the fact that the image is really an  
> external resource, and any internal HTML element value should really  be 
> considered an ALT tag from the point of view of rendering. Note  that 
> the same would apply to OBJECT elements.
> 
>> 2.5) Flexible subject/object referrals suggestion.
>>
>> Motivation 1:
>>
>>      One thing that RDF/A has not considered is the annotation of HTML
>> forms. Imagine sofware agents understanding the form semantically and
>> automagically carryout complex form filling (beyond username,  passwords
>> and personal information) on behalf of the user. I believe forms'
>> annotations will be extremely important for the semantic web.
> 
> 
> Forms annotation is indeed important, and is already possible with  the 
> current RDF/A. Remember that any XHTML element can be annotated.  What 
> we should do is add an example in the primer to show how this  can be 
> done, something along the lines of (this is XHTML1, just to  explain the 
> principle):
> 
> ======
> <form method="post" action="/foobar">
>    <meta property="dc:description" content="Login Form" />
> 
>    <input type="text" name="username">
>       <meta property="dc:title" content="username" />
>    </input>
> ...
> 
> </form>
> =======
> 
> With proper annotations, browsers could become much smarter about  what 
> they do with these forms, as you mention.
> 
> 
>> Motivation 2:
>>
>>      The use of content, href, about, id, are ways to specify the
>> subject and the object/value of the rdf statements. I feel that  they are
>> somewhat restrictive, especially when the author acknowledges that  there
>> are still some unavoidable duplication of content.
>>
>>      To further reduce duplication of URIs and literals, as well as to
>> cater for annotating HTML forms in the future, it would seem a more
>> flexible approach may be possible.
>>
>>      Assuming the subject and object of the rdf statement can be taken
>> from existing XHTML (or XML) element attributes, one can completely
>> avoid duplication by 'referring' to those attributes from another, for
>> example:
>>
>>      . <img src="http://....." attrAsStmtSubject="src">
>>
>>      . Normally the attrAsStmtSubject defaults to "about" and "id"
>>
>>      . <a href="http://....." attrAsStmtObject="href">
>>
>>      . Normally the attrAsStmtObject defaults to "href" and thus could
>> be unspecified.
>>
>>      . Similarly attrAsStmtValue="content",  attrAsStmtValue="CDData", or
>> any other attributes/text element.
>>
>>       Although I have not worked out the details, but I believe these
>> three new attributes (attrAsStmtSubject and attrAsStmtValue/Object)  are
>> compatible with RDF/A concepts, and I believe they will allow forms to
>> be annotated without much content duplication.
> 
> 
> The task force feels that much of the motivations for these changes  
> could be accomplished without any additional complexity (see form  
> annotation above). Certainly, your suggestion would further reduce  data 
> duplication, but only with significant added complexity in RDF/ A. 
> Extracting triples would become far more complicated, as the  values of 
> certain attributes would affect the actual parsing of the  rest of the 
> document. Thus, at this point, we would not want to adopt  this 
> recommendation.
> 
> 
> Thanks for some very useful and insightful comments. Please let us  know 
> if these answers give rise to new questions.
> 
> -Ben Adida
> ben@mit.edu
> 
> [1] http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues#src
> 

-- 
Free University Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Tel: +31 20 598 7739/7718; e-mail: schreiber@cs.vu.nl
Home page: http://www.cs.vu.nl/~guus/

Received on Monday, 23 January 2006 00:32:46 UTC