On 6/5/2011 9:52 PM, Simpson, Grant Leyton wrote:
> I am interested as well.
> I am curious, though, about the assertion that Microdata is winning out
> over RDFa. What's the basis for this assertion?
I'm not closely aware of developments in this area, so I may be
mistaken, but although the W3C has an RDFa specification recommendation
(at http://www.w3.org/TR/rdfa-syntax/ ), and there were some strong
reactions about the WhatWG HTML5 specification dropping RDFa in favor of
perhaps at least somewhat addressed by the fact that microdata does
provide a required formula for straight conversions to (though not from)
), namespaces and all, the specification driven by the browsers who
ultimately get to decide what support they build (and in the case of
Google, what formats they index, though Google is admittedly currently
supporting both RDFa and microdata) and seeing the most activity, the
fact that the WhatWG HTML5 specification to date (link above) only
mentions Microdata, it seems to me that the winds are blowing in that
There is a W3C debate at http://www.w3.org/html/wg/tracker/issues/76 ,
but the W3C, a non-governmental organization, trying to reign in the
browsers (even if that is not so relevant here, as meta-data is not
something really requiring browser support, since unrecognized
attributes and empty tags are not really problematic either way) seems
to my limited perspective like the currently constituted U.N. General
Assembly trying to control the veto-wielding members of the Security
Council; maybe the "Might Makes Right" situation is unjust for the
millions affected by browser decisions, but the former would I think
have to be pretty united to do anything about it... And WhatWG won out
already with HTML5 over XHTML2, even within the W3C, so I'm just
surmising the way things may go based on that experience...
Someone else with more of an actual clue, please feel free to correct... :)
In any case, though, Microdata is at least specified to such a degree as
to be able to convert to RDF, it seems to me adequate and simple enough
to use right now for TEI, though it will require some thought about the
best way to do it.
The biggest challenges to me seem to be deciding whether to take
advantage of the full range of HTML5 semantic tags (as the TEI
stylesheets do) which would offer better HTML5 semantics and probably
default styling, or just making it easier to convert in a very "no
exceptions" way, thereby making it easier for TEI readers to avoid
needing to learn much HTML5 and for an easier time making stylesheets. I
think I'm leaning to the former, but I think this merits a fuller
The former choice might also prompt what I think would be a welcome
discussion I've been hoping to see for a while about a more
human-readable (at least CSS-based) documentation (and potential for
further refinement) on how TEI elements might typically be understood by
default to be rendering:
http://wiki.tei-c.org/index.php/Comprehensive_CSS_Stylesheet since HTML
does lead to some default styling assumptions, even if they can be
> On 6/5/11 9:49 AM, "O'Donnell, Dan"<[log in to unmask]> wrote:
>> I'd be interested in working on this. Maybe there is a SIG we could
>> propose if enough people are interested in it.
>> Daniel Paul O'Donnell, PhD
>> Professor of English
>> University of Lethbridge
>> Sent from my Android phone using big thumbs on small keys.
>> -----Original Message-----
>> From: Brett Zamir [[log in to unmask]]
>> Received: Sunday, 05 Jun 2011, 6:50
>> To: [log in to unmask] [[log in to unmask]]
>> Subject: Official HTML5 Serialization of TEI
>> Hello all,
>> I am interested in seeing web apps develop to support TEI. I haven't had
>> a chance to check out the XQuery tool someone mentioned here, though I
>> did a little work on my own (at http://brettz9.github.com/xqueryeditor/ )
>> utilizing the XQIB library in more of a proof of concept (though one for
>> which I have a perhaps vain hope of finding time to develop it into
>> something more).
>> Besides being written using web standards, I would hope such a tool could
>> obtain TEI texts in a central, open repository. While there may be some
>> custom initiatives to bring TEI to the web, my thinking was that it might
>> be more effective for open (and especially potentially collaborative
>> markup) projects to use an HTML5 serialization which preserves all of the
>> semantic data, especially as it would allow texts to be shared without
>> need for tools supporting stylesheets. While microformats and RDFa seem
>> to still be around, it looks more like microdata is going to win out.
>> Microdata offers a systematic way to include the TEI namespace (albeit
>> with instead of an xmlns attribute) and besides the itemprop global
>> attributes, the HTML5 spec also specifically now allows<meta/> and
>> <link/> in the document body which I think should be rich enough to
>> define an official means of serializing TEI into HTML (and if contenting
>> oneself to a subset of HTML, serializing
>> back into TEI). But whatever could get consensus I think could work.
>> I think such a serialization would offer such benefits as:
>> a) It would not require customizable software to be previewed; TEI texts
>> could be made available at public sites such as Wikisource or sites based
>> on the same Mediawiki software, assuming
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=28776 would be implemented
>> (something more likely to be possible than expecting the less familiar
>> and non-historically-web-oriented language TEI to be accepted). The texts
>> could thus be previewed as structured HTML+CSS, allowing for conveniently
>> succinct wiki markup to be used to create such documents, while still
>> allowing incremental improvements (and revision control and history) to
>> the semantic mark-up as well.
>> b) It would be encoded in the format already most familiar to the web
>> community, albeit enhanced, in a standardly outlined manner, by TEI-based
>> semantic markup. It does add the additional burden that mark-up creators
>> must learn both HTML and TEI (though applications could utilize TEI as
>> the primary format, converting back to HTML when sending text to the
>> wikis, and merely storing HTML on the wiki)
>> c) Search engines such as Google (see
>> http://www.google.com/support/webmasters/bin/answer.py?answer=99170 ) can
>> discover such markup in a semantically-aware manner.
>> Does something like this interest anyone else?
>> I don't know whether it ought to be done as a modification of the default
>> TEI stylesheets, a simpler more predictable format (e.g., using divs for
>> pretty much everything rather than native HTML like blockquote), a schema
>> or what. Feedback on the idea is most welcome....
>> Best wishes,