RE: New RDFa Primer Draft

Hi Ben,

Looking good!

May I suggest a few other things? Hopefully--if you agree with them--they
won't be too much to add.

Sections 2.1 and 2.2
====================

The abstract at the beginning now says that our HTML documents are
"chock-full of structured data". I'm wondering if in the early stages of the
discussion we should maybe draw more attention to that. So, at the moment we
have in section 2.1 "she simply blogs about it", which is fine, followed by
the actual HTML mark-up, which is also good.

But *after* that I'm wondering if before it moves on to the substance of
2.2, we should say something simple like "even *this* mark-up is full of
metadata..." and then either highlight the metadata with a different
coloured background, or even better, go further into it and list each of the
items.

So what about this....we move section 2.2 up to 2.3, and have a new section
2.2 along the lines of "Jo's Data", which discusses the metadata that is
'packed' into the mark-up from 2.1:

<proposal>
  2.2 Jo's Data

  Even this short piece of mark-up is full of metadata:

  <em>I'm giving a talk at XTech 2006 on web widgets
  on May 8th, at 10am.</em>

  We have an <em>event</em> which is the talk that Jo
  is giving, and the event <em>starts</em> at 10am on
  May 8th. A <em>summary</em> of the event is "a talk
  at XTech 2006 on web widgets".

  <em>I'm a distinguished web engineer at Example.org,
  and can be emailed on jo@example.org.</em>

  Jo works for the <em>organisation</em> Example.org,
  with a <em>job title</em> of 'Distinguished Web
  Engineer'. She can be contacted at the <em>email</em>
  address 'jo@example.org'.

  At the moment it is very difficult for software like
  web browsers and search engines to make use of this
  large quantity of metadata, so we need a standard way
  to indicate what it is we are talking about. In the
  next section we will see how easy it is for Jo to
  use RDFa to mark-up this data and so make it easy to
  understand.
</proposal>

I think this does a couple of things:

  * it emphasises one of the main features, that
    we're going to help *reuse* this information,
    by flagging up to authors the amount of data
    they *already* pack into their blogs and web
    pages;

  * it also (sort of) explains what metadata is
    in a kind of sub-conscious way--we know that
    we don't really want to get into triples and
    such at this point, but without actually
    defining 'metadata' we've still indicated
    that the subject matter of our primer is the
    dates, the talk, the venues, the job titles,
    and so on;

  * it points forwards to the fact that by marking
    this data up clearly we can make use of it
    in software like web browsers to improve the
    user experience.


Section 2.2
===========

I'm thinking that this inserted section 2.2 also helps when you get to this
section (which would of course now be 2.3 if you agree with the changes),
since you've already conceptually set-up the bits of metadata that you are
going to add, like 'summary', 'dtstart', and so on.

The only change I'd suggest to this section is to make the final sentence
something more like the following:

  The above mark-up can now easily be interpreted as
  a set of RDF triples--we'll explain what that means
  in Section ??.

Whatever the exact wording, the main point I'm trying to make is that we're
making tiples available, rather than generating them; we have some mark-up
that could be *interpreted* as triples by a processor that feels inclined to
do so... :)


Section 2.3
===========

It's a shame that there is no 'vCard type' in the same way as there is
cal:Vevent, since it would make the whole 'drag this to your contacts
software' thing a lot easier to implement. I don't have any suggestions for
a solution...I'm just pondering. (Actually, one solution might be to have
some 'types' of our own...maybe we have some kind of more abstract @role
value that just means 'here is some contact info', and whether that info is
marked up with vCard or FoaF is irrelevant. Then we use those abstract role
values to drive the 'drag-and-drop features.)

I'm also thinking that a small addition here would be to put the address of
XTech in as a vCard too, and then reference it from the iCal event. Having
said that, I've looked at the RDF Schema for iCalendar and can't see how to
do this!

Anyway, I think this is hanging together pretty nicely!

All the best,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/




> -----Original Message-----
> From: public-rdf-in-xhtml-tf-request@w3.org 
> [mailto:public-rdf-in-xhtml-tf-request@w3.org] On Behalf Of Ben Adida
> Sent: 22 April 2006 17:14
> To: public-rdf-in-xhtml task force
> Subject: New RDFa Primer Draft
> 
> 
> 
> Hi all,
> 
> http://www.w3.org/2001/sw/BestPractices/HTML/2006-04-24-rdfa-primer
> 
> is the current draft of the RDFa Primer. Yes, I'm trying 
> "RDFa" on for size :)
> 
> The usual disclaimer applies: this document has no formal 
> standing within W3C and is subject change at any time.
> 
> Important changes to note:
> 
> 1) the Abstract is new.
> 
> 2) Section 2 is entirely rewritten, thanks to a very 
> productive offline discussion with MarkB (and a suggestion 
> due also to DanC). In particular, we stay away from the URI 
> ambiguity issues by using vocabularies (iCal and vCard) that 
> are less people-oriented. This also seems like the right way 
> to show people the power of RDFa: there are interesting, 
> natural things to share in current web pages, like events and 
> contact information, that RDFa can address quite well.
> 
> 3) Section 3 and 4 are mostly unchanged, except for the 
> dc:creator issue. From looking at the Dublin Core 
> documentation, it seems that dc:creator should be a literal. 
> So I made it a literal, and changed rel="dc:creator" to 
> property="dc:creator". Of course, it's currently an 
> XMLLiteral, so there may be some remaining issue to address here.
> 
> Note that I have *not* addressed Alistair's comment that a 
> XHTML fragment cannot also be a physical resource. Like Mark, 
> Jeremy, and Pat, I believe an XHTML fragment *can* also be a 
> camera or a person.  
> I'm sure we'll face opposition on this problem, but this goes 
> to the core of whether XHTML can be a first-class 
> serialization of RDF.
> 
> If it can't, it seems to me that the Semantic Web and the 
> Clickable Web are hopelessly disjoint, and we've got a 
> problem bigger than this task force.
> 
> 4) Section 5 (and eventually additional sections) will dig 
> into specific vocabularies, like FOAF, geoURL, etc... for 
> readers who are particularly interested in these specific 
> vocabularies. So far, they're not written up, and will likely 
> be written up in WD #3 (next
> WG....)
> 
> Note that I have not had time to address all comments by reviewers.  
> I'm going to try to do that over the next 2-3 days. If you 
> catch something specific, let me know ASAP.
> 
> -Ben
> 
>

Received on Sunday, 23 April 2006 11:03:02 UTC