- From: Ben Adida <ben@mit.edu>
- Date: Mon, 23 Jan 2006 07:47:15 -0500
- To: Guus Schreiber <schreiber@cs.vu.nl>
- Cc: SWBPD list <public-swbp-wg@w3.org>, public-rdf-in-xhtml task force <public-rdf-in-xhtml-tf@w3.org>
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:30 UTC