RDF in XHTML Task Force

Action Items

http://rdfa.info/wiki/Rdfa-profiles -- RDFa Profiles

ACTION: Manu to define a set of requirements and questions for extending CURIEs in an external document on the RDFa wiki. [recorded in http://www.w3.org/2009/04/30-rdfa-minutes.html#action11] [DONE]

ACTION: Manu to talk with Ben about recent WHATWG use case activity. [recorded in http://www.w3.org/2009/04/30-rdfa-minutes.html#action10] [DONE]

ACTION: Ben to put up information on "how to write RDFa" with screencast possibly and instructions on bookmarklet. [recorded in http://www.w3.org/2008/11/06-rdfa-minutes.html#action12] [CONTINUES]

benadida: This may be more important now
... Having a tool that can guide you if you do the wrong thing would be very useful.
... Because of the Google announcement this is important.

ACTION: Manu to write summary for Semantic Web Use Cases for Ivan. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action09] [CONTINUES]

ACTION: Mark create base wizard suitable for cloning [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action12] [CONTINUES]

benadida: We should make some simple wizards for Google available.
... should create an open/fun projects for the RDFa community

Ralph: Suggestions for undergraduate paper topics would be good.

ACTION: Mark to send Ben ubiquity related wizard stuff [recorded in http://www.w3.org/2008/11/20-rdfa-minutes.html#action11] [CONTINUES]

ACTION: Mark write foaf examples for wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action13] [CONTINUES]

ACTION: Michael to create 'RDFa for uF users' on RDFa Wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action14] [CONTINUES]

Steven: Microformats celebrating Google announcement.
... Bay area meetup dinner to celebrate.

benadida: Good for them

ACTION: Ralph or Steven fix the .htaccess for the XHTML namespace [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action01] [CONTINUES]

ACTION: Ralph think about RSS+RDFa [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action15] [CONTINUES]

Steven: RSS is an RDF format, right?

benadida: Yeah, but it has an RDF Sequence/Bag in there - it's a bit wierd/nasty to implement

Steven: If we markup each item, that would strike Ralph's action item.

ShaneM: We already do this.

*Collective celebratory cheers on Google support for RDFa*

benadida: Thanks a bunch to the group and Ralph for his hard work in making that happen.
... We should extend as much support for Google as possible in the coming weeks/months.

<ShaneM> As an aside - we are updating aptest.com right now to use RDFa and the google annotations for some of our popular pages.

<benadida> interesting discussion: http://intertwingly.net/blog/2009/05/12/Microdata

Future of RDFa - XG

benadida: Does this make sense?
... What's the point of the incubator group?

Ralph: In this context, the incubator group is somewhere between an IG and a WG.
... and IG can produce a Note.

benadida: To update the REC we need to be a WG?
... If we want to be able to update RDFa, we need to be a WG?

Ralph: Yes.

benadida: That takes a while to become a WG?

Steven: The REC isn't a product of this task force anyway.
... We already have a WG that support the spec - Semantic Deployment WG, and XHTML2 WG.

Ralph: SWD WG goes away soon, probably don't want to do the update in XHTML2 WG.
... It would be too much overhead in HTML WG to do this right now.
... Goal is to produce a proposal specification.
... The next step after that would be to produce a REC.
... The best path is an XG to get RDFa in HTML proposed specification completed.
... The XG would get all of the resources that we currently get in RDFa TF to keep minutes, telecon time, etc.
... If SWIG was being run as a group that holds meetings, but they don't run that way, so it would be a bad fit.
... We want to meet and get the technical work done - XG Report would be the best mechanism to do that.

benadida: But we do want this to become a REC.

Ralph: Yes, so the charter for the XG should be clear that the next step is to get the proposals to REC.

benadida: I think the XG makes sense.

Ralph: We need 3 W3C members sponsoring it.

+1 for XG

Ralph: HTML WG charter lists extension mechanism that allows RDF and other things to be done - that is RDFa.

benadida: Ralph can you talk about the XG idea at W3C?

Ralph: yes.
... We could also do it as a Task Force in SWIG, but it may not be a good fit.

RDFa in HTML

benadida: Shane?

ShaneM: I put together a draft so that we had something to poke at.
... URL is in the IRC channel.
... A couple of issues that may be good to review.
... We could say that RDFa just works in HTML4 (because it does).
... The first issue is about announcement - How does a conforming RDFa processor know that the document contains RDFa?
... I talked with Manu a bit about this - DOCTYPE, or @version attribute, or @profile attribute with a specific value.

Ralph: You actually don't need to do any of those things because of GRDDL...

ShaneM: I don't think the GRDDL spec does what we want.

benadida: It works for XML documents, not for HTML4.

ShaneM: No requirement that there should be a DOCTYPE, but it may be okay for us to say that there should be a DOCTYPE.
... We should have pushed for DOCTYPE in XHTML1.1+RDFa more - that's how most user agents figure out which standards mode to enter.
... So, we might want to think about requring a DOCTYPE

benadida: We should review that and in fairly short order, send it to the HTML WG.
... We should have HTML4 examples with RDFa in them.
... This document looks like it's taking the right approach.
... We should have a complete example, top to bottom.

ShaneM: Didn't want to duplicate too much.
... Also, there is an issue about XML Literals.

<ShaneM> XMLLiterals: If the object of a triple would be an XMLLiteral, but the resulting object would not be well-formed [XML], then the processor MUST NOT generate the triple.

Manu: We don't require this in the RDFa spec.

ShaneM: No, it's implied since it is in XHTML spec.

Manu: Well it's a problem in HTML4.

Ralph: We don't say what processors should do.

ShaneM: It's up to the processor to make it well-formed.

Steven: This would be an interoperability issue...

ShaneM: One processor may generate it, another may not.
... We could say the input must be well-formed... or the output must be well-formed... or
... When the input is well formed, you can output an XML Literal, whent he input is not well-formed, you must output something else.

benadida: To do RDFa, you have to have a DOM-based model.
... We assume a tree of nodes.

ShaneM: I disagree.

benadida: The fact that it is a tree, at some point you have some child nodes.
... You're going down some tree structure... you must have some well-formed representation of your child nodes. Not well-formed in the XML sense.

ShaneM: The processing model isn't written that way.
... It says that the next thing coming is an XML Literal.

benadida: Maybe I'm biased by my implementation?

ShaneM: If you have a tree, you can generate well-formed output (by definition).

Steven: HTML processors process HTML as a tree - the output is a serialization of that tree.

ShaneM: We're talking about extracting triples from HTML...

Ralph: Sounds like your objective would be to state that "you should only generate well-formed XML literals and may do that even if the input is not well-formed".".

benadida: When you put it that way, I don't like it.

ShaneM: Also, this doesn't have anything to do with HTML5 - it has to do with HTML4.

benadida: What's the other option? To not generate the triple?

ShaneM: In terms of inter-operability - that is /the/ option.
... Every processor should generate the same triples.
... If the input is not well-formed, then don't generate the triple.

ShaneM: If you're able to make the input well-formed, then do so.

Ralph: Not comfortable with that approach.
... We should depend on adopting the solutions that give us the greatest amount of interoperability.

benadida: Is there anything close to an "HTMLLiteral"?

ShaneM: We could say "if the input is well-formed, then you can produce an XML Literal"
... If the input is not well-formed, output an RDF string.

benadida: as long as we can round-trip it.

Ralph: That choice is attractive, except for one thing.
... There may be an algorithm for XML serialization of tag soup.
... If we require that non-well-formed things be anything, it makes it difficult to adopt that algorithm in the future.
... I'd rather not generate the triples today.

Steven: gotta go

benadida: The options we have on the table
... 1) Don't generate the triple.
... 2) Find an XML Serialization for it.

Ben: 3) If it's not well-formed, make it an RDF escaped string.

Ralph: Some people will treat strings equivalent to XML Literals.
... The real-world doesn't like it when you punt on first-error... browsers don't punt on first-error.
... People get unhappy when their page doesn't display.

benadida: Maybe this is a way to coerce people into writing well-formed XML :) (joke)

Ralph: We should make it easier for them to write the correct markup.

ShaneM: This is a very niche thing...
... The data that gets encoded isn't a web page, it's a title of a book that has markup.

benadida: It is a niche case.

<benadida> <span property="dc:title" datatype="">foo<em>bar</span>

<benadida> foobar

<benadida> <span property="dc:title" datatype="">foo<br>bar</span>

<Ralph> alternatively "foo&lt;br>bar"

Ben: no, if the author used @datatype="" they clearly meant the embedded tag to be dropped

Ralph OK, I see your reasoning

<benadida> <br> --> <br />

benadida: that would be an XML Literal if you did the transform.

ShaneM: If the author wants to preserve content that is not well-formed, there is an alternative.

benadida: if it's anything other than XMLLiteral, we strip the non-text nodes for everything other than XMLLiteral.

<ShaneM> If the object of a triple would be an XMLLiteral, but the input to the processor is not well-formed [XML], then the processor MUST NOT generate the triple.

benadida: The only option I think I support is no triple generation.

Ralph: you can force a triple to be generated with mal-formed input.

benadida: Generally, we don't support non-well-formed markup in a literal.
... We should review the document that Shane's put together. Send comments on the list ASAP.

Ralph: Maybe the IG should work on this document. Does it make a difference if we publish an early version of the document.
... I don't think it makes a difference.

benadida: Okay, discuss on the mailing list.