Should we really use RDFa?

[MURATA Makoto]

Dear colleagues,

I seriously doubt whether EPUB3 should use RDFa. Shouldn't we
drop them and go back to what EPUB2 does?

First, we really do not know what will happen to RDFa in HTML5.

Bug 13101 - TAG issue on HTML+RDFa and Microdata last call drafts
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13101

Bug 13100 - TAG issue on HTML+RDFa and Microdata last call drafts
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13100

Second, Schema.org uses microdata rather than RDFa. (Conversion to
RDFa is trivial though).

Third, RDFa has not been successful. In Google+, Ian Hickson (HTML5
spec editor) wrote:

RDFa: A horribly-designed technology that built on a technology
without broad adoption. While
it was the only game in town, it gained some traction, but its
horrible usability actually pushed
some of its biggest adopters (e.g. Google) to seek alternative
solutions. End result: A vastly
simpler technology designed to address the use cases that people
actually care about that
ignores the theoretical is developed. The RDFa community try to
form a task force to do
something about it. What happens next is as yet undetermined.

https://plus.google.com/107429617152575897589/posts#107429617152575897589/posts

Fourth, RDFa keeps changing. For example, @profile might be dropped. See
Issue 153 http://code.google.com/p/epub-revision/issues/detail?id=153

Sixth, I also know that our use of RDFa deviates from the original
intention. EPUB3 uses
<meta> when <link> was intended by the designer of RDFa.

--

Praying for the victims of the Japan Tohoku earthquake

Makoto

[Bill McCoy]

Dear Makoto,

Markus is on vacation presently so I will try to respond:

- What do you mean "go back to what EPUB2 does"? I didn't think EPUB 2 had any means for adding content-level annotations, i.e. semantic inflection. Or was this an indirect way to suggest that we drop this feature altogether?

- You mention that EPUB 3 deviates from RDFa spec as if that's one of the problems, but it's my understanding that the WG decided for this precisely to avoid your previously listed problem about RDFa not being finalized. I.e.  I understand it, we aren't supporting RDFa per se but something that is like a subset of RDFa, in a way that insulates us from changes to same. Do you have this same understanding?

- I'm not an expert in this area but I am also troubled that RDFa remains controversial and unstable and unsure about whether our solution in this area for EPUB 3 will look optimal in hindsight. But it is very late in our process to be revisiting WG decisions and I'm disinclined to have the trigger to drop or completely redesign important functionality be a blog post from someone who almost certainly would take issue with many aspects of EPUB (e.g. our use of XHTML). The use case of EPUB for publications is different than the use case of plain HTML for websites and we don't have the overriding concern about backwards compatibility with "tag soup" content that tends to dominate everything else in the evolution of the Web. And we obviously still care about publications aka documents, not just Web applications.

Best,

--Bill

--

Bill McCoy

Executive Director

International Digital Publishing Forum (IDPF)
bmc...@idpf.org

+1 (206) 353-0233

[Peter Sorotokin]

Makoto,

We do not use RDFa in HTML, and we only use what could be called RDFa-like syntax in OPF file for metadata. That new metadata functionality was very well received, as far as I can tell, and dropping it without a replacement would generate a lot of negative press for us. It does not matter if RDFa keeps changing, because OPF syntax does not depend on it.

Ian is well-known for his combative arguments and using the important position that he has in standards world to propagate his personal views. Being a very intelligent person, in many cases he ends up being right, but his views on RDFa do not represent any sort of consensus.

I have big problems with microdata not having any sort of namespace support, so I do not see it as a good replacement for RDFa.

Peter
________________________________________
From: epub-work...@googlegroups.com [epub-work...@googlegroups.com] On Behalf Of MURATA Makoto [eb2m...@asahi-net.or.jp]
Sent: Monday, July 25, 2011 6:39 AM
To: epub-work...@googlegroups.com
Subject: Should we really use RDFa?

[MURATA Makoto]

Bill and Peter,

I proposed a radical solution so that the reasons for our design choice become
clear and documented. I withdraw my proposal to drop RDFa at this stage of the
game. But I am still concerned about details of our metadata design.

> - You mention that EPUB 3 deviates from RDFa spec as if that's one of the
> problems, but it's my understanding that the WG decided for this precisely
> to avoid your previously listed problem about RDFa not being finalized. I.e.
> I understand it, we aren't supporting RDFa per se but something that is
> like a subset of RDFa, in a way that insulates us from changes to same. Do
> you have this same understanding?

I'm afraid not.

EPUB3 uses <meta> when RDFa intends <link>. Our design looks simpler
for mere mortals and some others do the same thing. But the RDF graph
represented in our approach is different. Look at the two graphs, available
at http://twitpic.com/5c74mt The lower graph is represented by an
example in Clause 3.4 of EPUB Publications 3.0. Note that this lower
graph consists of two disconnected subgraphs. Meanwhile, the upper graph
is a single graph and would be represented by a <link>-based
representation, namely:

<link rel="marcrel:aut" href="#creator">
<meta about="#creator" property="rdf:value">Haruki Murakami</meta>
<meta about="#creator" property="rdf:value" xml:lang="ja">村上春樹</meta>
<meta about="#creator" property="file-as">Murakami, Haruki</meta>

At the very least, we should explain our design choice and sketch
conversion to <link>-based representations.

Another issue is:

> @profile might be dropped. See

> Issue 153 http://code.google.com/p/epub-revision/issues/detail?id=153]

I will submit more issues to our issue tracker.

[Markus Gylling]

Hi all,
Murata-san, thanks for raising this; in fact and given the recent TAG activity, I had intended to raise the same issue directly as I come back from vacation (which, believe it or not, is only a few days from now).

I suggest we have a concall next week to discuss our options thoroughly. As Peter points out, our use of RDFa in the package file, while using a simplified subset of RDFa, satisfies the functionality that the metadata subgroup required for EPUB3. While RDF graph problems in this approach have been identified, there is another overarching problem that I think we need to look at first: we are normatively referencing a set of constructs in the RDFa 1.1 spec (attribute definitions and datatypes), that (as Murata-san indicates in his initial email) given the new TAG issues may change radically before the situation stabilizes at the W3C side (changes to @profile is potentially only one example).

As far as I can tell, that alone provides enough reason for us to consider making changes to the EPUB3 spec. Others may of course disagree, but it seems to me that - somewhat contrary to how the situation looked a year ago - this is not a good point in time to adopt an existing W3C metadata solution by reference; the landscape is changing rapidly, on a timeline that no longer matches ours.

I hope we can agree here that *if* we make changes, such changes do not include removal of any of the new functionality added to package metadata in EPUB3 (e.g. fragment expressions, declarative vocabulary associations, external resource identification, and so on). What I think we need to discuss is whether we want to consider alternate approaches to achieving that functionality. (Note that such alternate approaches do not necessarily imply large lexical changes.)

Suggested time for concall: Wednesday August 3, 21:00 UTC. If you intend to participate actively but can not make this time, let me know, and we'll try to reschedule. The metadata subgroup will prepare a wiki page for solution options in the meanwhile.

/markus

[MURATA Makoto (FAMILY Given)]

I wrote:

> First, we really do not know what will happen to RDFa in HTML5.
>
> Bug 13101 - TAG issue on HTML+RDFa and Microdata last call drafts
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13101
>
> Bug 13100 - TAG issue on HTML+RDFa and Microdata last call drafts
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13100

I just learned that the TAG comments are unlikely to lead any changes
to the W3C Recommendation RDFa 1.0.

Cheers,
Makoto

[Markus Gylling]

Murata-san,
I assume you mean 1.1, not 1.0.

I will have a discussion with Manu Sporny within the next few days to discuss the matter further. Will report back.

/markus

[MURATA Makoto]

2011/8/4 Markus Gylling <markus....@gmail.com>:

> Murata-san,
> I assume you mean 1.1, not 1.0.

I meant that 1.0 will not change but 1.1 might. Our spec uses
1.1 but do we use any mechanisms specific to 1.1?

> I will have a discussion with Manu Sporny within the next few days to discuss the matter further. Will report back.

Great! Looking forward to your report.

Regards,
Makoto

[matt.g...@bell.net]

> do we use any mechanisms specific to 1.1

The profile and prefix attributes are new to 1.1. Going back to 1.0 would mean no default vocabulary and only the xmlns method of prefix mapping.

And we'd still have the problem of broken RDFa expressions.

Matt

> Date: Thu, 4 Aug 2011 21:37:24 +0900
> Subject: Re: Should we really use RDFa?
> From: eb2m...@asahi-net.or.jp
> To: epub-work...@googlegroups.com

[Markus Gylling]

I talked to Manu Sporny, chair of the W3C RDFa working group.

We discussed primarily the Microdata/RDFa taskforce, its timelines and deliverables. It is clear that the task force is still in its early stages, has some challenging work ahead, and that it is therefore very difficult to predict the outcome and timeline at this point. 

With regards to the stability of RDFa 1.1 Core (from which we draw the small subset for use in the Package File) Manu estimated the following:

 * If the taskforce outcome is to change nothing (Microdata and RDFa to continue on separate paths, which some believe is a likely outcome), then RDFa Core is approximately 95% stable now.

 * If the taskforce outcome is to merge the two, then nobody knows the extent of changes that will occur. [1]

In terms of the first option: if it was decided to bring RDFa Core to REC as-is (with the remaining 5% changes done) today, Manu estimates it would take the WG 3-4 months to completion; this includes a new LC cycle. But at this time (and as I understand it), the decision on whether to take the Core spec further on the rec track is on hold, awaiting the taskforce outcomes.

As Murata-san has asked about the possibility of using RDFa 1.0 instead earlier in this thread -- Manu also reminded me that RDFa 1.0 is only defined in terms of XHTML, so it formally cannot be applied to other host languages such as the Package grammar. (Manu also pointed out that in spite of this, most implementations of RDFa 1.0 actually do work on other host languages as well.)

Finally, Manu said that as the taskforce is being formed, he is hoping that parties such as IDPF and IPTC will be invited to it. 

[1] See some early strawman work from Jeni Tennison here: http://www.jenitennison.com/blog/node/162

/markus

[MURATA Makoto]

Markus,

Thank you very much for your report. Do we basically have three options?

A: Status quo (RDFa 1.1 subset) and hope that the taskforce will not
change anything.

B: RDFa 1.0 + our own extensions

C: Invent our own syntax and semantics
(I think that this approach open a can of warms, since we are no
longer constrained by RDFa and we cannot rely on RDFa.)

Regards,
Makoto

2011/8/9 Markus Gylling <markus....@gmail.com>:

--

[Markus Gylling]

Murata-san,

> Do we basically have three options?

yes, those are the options we have identified at this time, where C was the one discussed on last weeks call. Some comments:

* Re B: Adding our own extensions to 1.0 means that B is really no different C from a standards compatibility perspective. B would also yield the highest risk of misinterpretation; appearing to use a processing model defined elsewhere, when it actually isn't. (Remember that C includes the notion of introducing some milder name changes to avoid this effect)

* Re C: As discussed on the call last week, C can in its current state be described as a) reverting to allow all of the dc:* elements used in epub 2.x, and b) extending the functionality of the 2.x meta element (including changed syntax, while allowing the old syntax as well for compat purposes). I used the term "roll our own" last week, but have come to regret that: the dc:* elements are and have always been defined in concordance with Guidelines for implementing Dublin Core in XML [1], and the extended meta element could use some of the principles/naming conventions described herein as well.

* As pointed out before, for both A and B we also have the graph problems that would need to be resolved, with a risk of more complicated syntax as a result.

[1] http://dublincore.org/documents/dc-xml-guidelines/

/markus