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

Guus,

Sure, it's in the same location:
http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-15-rdfa-primer

We have promised some changes to Pat and Gary according to their  
feedback, which we'll be making over the next 2-3 weeks. But for now,  
the version is the same as before.

-Ben

On Jan 22, 2006, at 8:19 PM, Guus Schreiber wrote:

> Ben,
> Yes, I will. Can you send mail to the list about the status/ 
> location of the version we should decide about?
>
> Thanks,
> Guus
>
>
> Ben Adida wrote:
>> Guus,
>> Yes, we would like to ask the working group to approve moving the  
>> RDF/ A Primer to Working Draft status. We'd like to spend the 3- 
>> month  extension to continue to get feedback from the WG and to  
>> add more  examples.
>> If this vote can be squeezed into tomorrow's telecon agenda, that   
>> would be fantastic.
>> -Ben
>> On Jan 22, 2006, at 7:32 PM, Guus Schreiber wrote:
>>>
>>> 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/
>>>
>
> -- 
> 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 12:47:47 UTC