- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 9 Jun 2009 08:40:54 +0000 (UTC)
On Mon, 11 May 2009, Simon Pieters wrote:
> On Sun, 10 May 2009 12:32:34 +0200, Ian Hickson <ian at hixie.ch> wrote:
>
> > Page 3:
> > <h2>My Cats<h2>
> > <dl>
> > <dt>Schrödinger
> > <dd item="com.damowmow.cat">
> > <meta property="com.damowmow.name" content="Schrödinger">
> > <meta property="com.damowmow.age" content="9">
> > <p property="com.damowmow.desc">Orange male.
> > <dt>Erwin
> > <dd item="com.damowmow.cat">
> > <meta property="com.damowmow.name" content="Lord Erwin">
> > <meta property="com.damowmow.age" content="3">
> > <p property="com.damowmow.desc">Siamese color-point.
> > <img property="com.damowmow.img" alt="" src="/images/erwin.jpeg">
> > </dl>
>
> Given the microdata solution and this example, there is now a reason other
> than styling to introduce <di>, since here you duplicate the <dt> information
> in <meta>.
>
> <dl>
> <di item="com.damowmow.cat">
> <dt property="com.damowmow.name">Schrödinger
> <dd>
> <meta property="com.damowmow.age" content="9">
> <p property="com.damowmow.desc">Orange male.
> </di>
> ...
>
> The styling problem is discussed at
> http://forums.whatwg.org/viewtopic.php?t=47
Yeah, I noticed that. I agree that if it turns out that this is a common
authoring pattern (and assuming we can work around the difficulties in
adjusting the parser to handle this), we should probably introduce <di>
after all. I intend to wait and see what happens first though.
On Mon, 11 May 2009, Giovanni Gentili wrote:
> Ian Hickson:
> > ? USE CASE: Annotate structured data that HTML has no semantics for, and
> > ? which nobody has annotated before, and may never again, for private use or
> > ? use in a small self-contained community.
> > (..)
> > ? SCENARIOS:
>
> Between the scenarios should be considered also this case:
>
> * a user (or groups of users) wants to annotate
> items present on a generic web page with
> additional properties in a certain vocabulary.
> for example Joe wants to gather in a blog
> a series of personal annotation to movies
> (or other type of items) present in imdb.com.
This isn't really a use case, it's a solution. What is the end-user
scenario that the author is trying to address? For example, what kind of
software will collect this information? What problem are we solving?
> a) In the case of properties specified for element without ancestor with
> an item attribute specified the corresponding item should be the
> document? (element body with implicit item attribute).
We already have mechanisms for providing name-value pairs for a document;
namely, <meta name> and <link rel>.
> b) Do we need to require UA to offer a standard way to visualize (at
> least as an option left to the user) the structured information carried
> in microdata ?
Not as far as I can tell; what use case would this be for?
> And copy&paste?
The spec already requires user agents to include microdata in copy and
paste.
On Tue, 12 May 2009, Tim Tepa?e wrote:
> >
> > (Note the <meta>s in the last example -- since sometimes the
> > information isn't visible, rather than requiring that people put it in
> > and hide it with display:none, which has a rather poor accessibility
> > story, I figured we could just allow <meta> anywhere, if it has a
> > property="" attribute.)
>
> That seems to be a solution optimised for extremely invisible metadata
> but not for metadata which differs from the human visible data.
It handles both -- instead of:
<span itemprop="x">y</span>
...you can do:
<span><meta itemprop="x" content="y">z</span>
> Imagine as an example the simple act of marking up a number (and
> ignoring what the number denotes). For human consumption a thousands
> seperator is often used, the type of seperator differs by language,
> locale and context. Just in my little word I see on regular basis the
> point, the comma, the space, the thin space and sometimes the the
> apostrophe. Parsing different representations of numbers would be a
> chore. The value of textContent of the element <span
> itemprop="com.example.price">? 1thinsp;000thinsp;000,—</span>
> is clearly unusable, demanding an additional invisible <meta
> property="com.example.price" content="1000000">.
Right.
> My irritation lies in the element proliferation, requiring one element/
> attribute combination for machines, one element/text content combination
> for humans. Of course, any sane author would arrange both elements in a
> close relation, as parent/child or sibling but there would be still two
> different elements to maintain, leading to a higher cognitive load. Not
> just for authors but also for programmers: a fluctating price had to be
> actualized on two different elements; tree walking DOM scripts had to
> take meta-Elements in account. Furthermore it clashes with the familiar
> habit of other elements in HTML. A hyperlink is one element with a
> machine-readable attribute and human- readable text content. A citation
> is one element with a machine-readable reference and human-readable text
> content. The same model is used in <meter>, <progress>, <time>, <abbr>
> ... but not in user-defined objects. I'd prefer an additional
> @content-like attribute which supersedes the text content and maybe even
> the default values of the other value-bearing elements, reducing two
> different elements to maintain or change to just one.
I don't really understand what you are proposing. How would you reduce the
number of places where the value is represented?
I think on the long run if we find particular data types (such as numbers)
are commonly used in these scenarios, we'll just introduce a new element
like we did for dates and times (<time>), which can then just render the
number in a locale-specific manner automatically.
> > Instead, let us try using the regular "IDREF" functionality that HTML
> > uses in a variety of other places, like <label for="">. For this we'll
> > need a new attribute, but unfortunately we can't use about="" (which
> > would be the obvious name to use), because that would conflict with
> > RDFa, so instead we'll use subject="":
>
> I'm slighty irritated by the implied change from active, possessive
> formulating (?The cat has the name Hedral.?) to something more passive-y
> (?Hedral is a name owned by that cat.?). My mental model for property
> relationships orients itself more on the former wording; link
> relationships are similar in that regard. @about/@subject are like @rev;
> a @resource alias @rel would feel more natural. There are practical
> relation by the missing @resource, I think. Imagine a document
> documenting an household and a household vocabulary which allows triples
> of <human>s which are in an <owner> relationship to a <cat>. Given an
> household of two humans and one cat; how does one markup the assumption
> that the cat has two owners?
I agree that there are use cases for both subject="" like "reverse" links
back to an item, and "inclusion"-style links that embed other data into an
item. I have a rough proposal in the form of a <ref> element that could be
used to do inclusions (based somewhat on the Microformats include
pattern), but I think we should wait to see how well microdata works in
the wild before we start adding more features. If it turns out that
microdata doesn't work, then there's no point worrying about inclusions!
On Tue, 12 May 2009, Eduard Pascual wrote:
>
> First issue: it solves a (major) subset of what RDFa would solve.
> However, it has been taken as a requirement to avoid
> clashes/incompatibilities with RDFa. In other words, as things stand,
> authors will face two options: either use RDFa in HTML5, which would
> forsake validation but actually work; or take a less powerful, less
> supported (at least for now: many RDFa-aware agents vs. zero HTML5's
> microdata -aware agents) that validates but provides no pragmatic
> advantages.
>
> IMO, an approach that forces authors to choose between
> validity/conformance which doesn't *yet* works vs. invalid solutions
> that actually work is a horrible idea: it encourages authors to forsake
> validity if they want things to work.
>
> Wouldn't the RDFa + @prefix solution suggested many times work better
> and require less effort (for spec writters, for implementors, and for
> content authors)? Keep in mind that I don't think RDFa + @prefix is the
> solution we need; I'm just trying to point out that the current approach
> is even worse than that.
I covered the problems with RDFa in the e-mail introducing microdata:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html
I agree that introducing yet another proposal for this is unfortunate, but
I couldn't find a way to address RDFa's issues (or Microformat's issues,
or the issues with a number of other technologies I looked at) without
changing RDFa in an incompatible manner. I believe the problems with
introducing yet another technology to do this are minor compared to the
problems with the existing technologies.
> Second issue: as the "decaffeinated RDFa" it is, the HTML5 Microdata
> approach tends to fail where RDFa itself fails. It's nice that, thanks
> to the <time> element, the problem with trying to reuse human-readable
> dates as machine-readable is dodged; but there are other cases where
> separate values might be needed: for example using a street address for
> the human-readable representation of a location and the exact geographic
> coordinates as the machine-readable (since not all micro-data parsers
> can rely on Google Maps's database to resolve street addresses, you
> know); or using a colored name (such as "lime green" displayed on lime
> green color) as the human-readable representation of a color, and the
> hexcode (like #00FF00) as the machine-readable representation. These are
> just the cases from the top of my head, and this can't be considered in
> any way a complete list. While *favoring* the reuse of human-readable
> values for the machine-readable ones is appropiate, because it's the
> widely most common case, *forcing* that reuse is a quite bad idea,
> because it is *not* the *only* case.
Microdata doesn't force that reuse; you can use <meta> instead.
> Third issue: also a flaw inherited from RDFa, it can be summarized as
> completelly ignoring the requirement I submitted to this list on April
> 28th, in reply to Ian asking us to review the use cases [1]. I'll try to
> illustrate it with a example, inspired by the original use-case: Let's
> say someone's marking up a collection of iguanas (or cats, or even CDs,
> doesn't really make a difference when illustrating this issue), making a
> page for each iguana (or whatever) with all the details for it; and then
> making an "index" page listing the maybe 20 iguanas with their name,
> picture, and link to the corresponding page. Adding micro-data to that
> "index", either with RDFa or with Ian's microdata proposal, would
> involve stating 20 times in the markup something like "this is the
> iguana's picture; this is the iguana's name; and this is the iguana's
> URL". It would be preferable to be able to state something like "each
> (row) <tr> in the <table> describes an iguana: the <img>s are each
> iguana's picture, the contents of the <a>'s are the names, and the @href
> of the <a>'s are the URLs to their main pages" just once. If I only need
> to state the table headings once for the users to understand this
> concept, why should a micro-data consumer require me to state it 20
> times, once for each row? Please note how such a page would be quite
> painful to maintain: any mistake in the micro-data mark-up would
> generate invalid data and require a manual harvest of the data on the
> page, thus killing the whole purpose of micro-data. And repeating
> something 20 (or more) times brings a lot of chances to put a typo in,
> or to miss an attribute, or any minor but devastating mistake like
> these.
I agree entirely. I actually tried to find a workable solution to address
this but unfortunately the only general solutions I could come up with
that would allow this were selector-based, and in practice authors are
still having trouble understanding how to use Selectors even with CSS.
There's also the problem with separating the data from the rules that say
how to interpret the data, which would likely lead to more problems than
the typos one would get from repeating the itemprop=""s.
I'll probably look at this again in more detail when responding to the
thread specifically on this topic.
> Last, but not least, I'm not sure if it was wise to start defining a
> solution while some of the requirements seem to be still under
> discussion.
Well, they were under discussion for about a year; at some point we have
to just do something, or else this feature would have missed the HTML5
train altogether.
On Wed, 13 May 2009, Eduard Pascual wrote:
> On Sun, May 10, 2009 at 12:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> > [...]
> > * Any additional markup or data used to allow the machine to understand
> > the actual information shouldn't be redundantly repeated (e.g. on each
> > cell of a table, when setting it on the column is possible).
> >
> > This isn't met at all with the current proposal. Unfortunately the only
> > general solutions I could come up with that would allow this were
> > selector-based, and in practice authors are still having trouble
> > understanding how to use Selectors even with CSS.
>
> First, I'd like to ask for a clarification from Ian: what do you mean by
> "autrhos are still having trouble understanding how to use Selectors"?
> If you mean that they have trouble when trying to select something like
> "the second cell of the first row that has a 'foo' attribute different
> from 'bar' within tables that have four or more rows" or even more
> obscure stuff, then I should agree: most authors will definitely have
> trouble dealing with so complex cases, and I bet many will always have
> such trouble. However, if you mean that authors can't deal with simple
> class, id, and/or children/descendant selectors, then I think you are
> seriously understimating authors.
I was referring to the kind of selectors one would need to make good use
of a semantic-extraction mechanism using selectors.
> Actually, I was thinking about the cost of deploying implementations,
> rather than writting them, since RDFa consumers are already out there
> and working. This, however, strays a bit out of the original idea: it's
> not really a matter of how big the cost is on its own, but of what do
> you get for that cost. This is probably my own fault, but I still fail
> to see what Ian's suggestion offers that RDFa doesn't; so my impression
> is that these costs, even if they are small, are buying nothing, so they
> are not worth it. If someone is willing to highlight what makes this
> proposal worth the costs (ie: what makes it better than RDFa), I'm
> willing to listen.
The main benefit as I see it is is simplicity. I've seen even RDFa
advocates stumble over exactly what triples get generated from some
particularly gnarly RDFa snippets. With microdata, there's really no way
to form a gnarly snippet. Each group is introduced by an item="", each
name/value pair is introduced by an itemprop="", and there's subject="" to
handle non-nested cases. No prefixes, no CURIEs, no rel vs rev, no data
types, no hanging triples, no resource="" vs src="", etc.
On Tue, 12 May 2009, Shelley Powers wrote:
> >
> > If we can come up with a way of using the string "foaf:name" without
> > having to declare "foaf" in each document, I'm totally in agreement.
> > I've considered maybe registering the "foaf" URL scheme, or using some
> > other punctuation character and having people register prefixes, but I
> > don't know what punctuation character to use (':' and '.' are both
> > taken).
>
> But then we would lose the extensibility, which is the power behind all
> of this.
I don't see why registering particular prefixes involves losing
extensibility... aren't URI's extensible?
> But regardless, the majority of people will include metadata markup by
> installing a plug-in or module, and making a couple of choices. And if
> you put together a good ten-minute tutorial for the average developer,
> they'll have no problem with "foaf:name". Training and clarity of
> communication is much ore important than form, it always has been with
> technology.
I think you significantly underestimate the difficulty of getting Web
authors interested in doing the right thing.
On Wed, 13 May 2009, Leif Halvard Silli wrote:
>
> CSS and selectors appears to be one of the best understood technologies
> of the web.
That certainly hasn't been my experience, at least not with anything
beyond the simplest of selectors.
On Wed, 13 May 2009, Giovanni Gentili wrote:
> >
> > If we can come up with a way of using the string "foaf:name" without
> > having to declare "foaf" in each document, I'm totally in agreement.
> > I've considered maybe registering the "foaf" URL scheme, or using some
> > other punctuation character and having people register prefixes, but I
> > don't know what punctuation character to use (':' and '.' are both
> > taken).
>
> put in HTML5 some predefined prefixes for @itemprop:
>
> dc = http://purl.org/dc/terms/
> foaf = http://xmlns.com/foaf/0.1/
> vcard = http://www.w3.org/2001/vcard-rdf/3.0#
> owl = http://www.w3.org/2002/07/owl#
> rdf = http://www.w3.org/1999/02/22-rdf-syntax-ns#
> rdfs = http://www.w3.org/2000/01/rdf-schema#
> sioc = http://rdfs.org/sioc/ns#
> skos = http://www.w3.org/2004/02/skos/core#
> xsd = http://www.w3.org/2001/XMLSchema#
If we're going to predefine things, we're better off predefining all the
terms so that we don't need prefixes at all.
> also, instead of @item @itemprop @subject
> is better @item @prop @subj
Why is that better?
> or @rdf-typeof @rdf-property @rdf-about (and @rdf-rel)
This isn't really about RDF, so I think that would be confusing.
On Thu, 14 May 2009, Shelley Powers wrote:
>
> Actually, I believe there are other differences, as others have pointed
> out.
>
> http://www.jenitennison.com/blog/node/103
>
> http://realtech.burningbird.net/semantic-web/semantic-web-issues-and-practices/holding-on-html5
>
> Some of the differences have resulted in more modifications to the
> underlying HTML5 spec, which is curious, because Ian has stated in
> comments that support for RDF is only a side interest and not the main
> purpose behind the microdata section.
Even side interests need some love.
On Thu, 14 May 2009, Philip Taylor wrote:
>
> If I understand RDF correctly, the idea is that everything can be
> URIs, subjects and objects can instead be blank nodes, and objects can
> instead be literals. If we restrict literals to strings (optionally
> with languages), then I think all triples must follow one of these
> eight patterns:
>
> <urn:subject> <urn:predicate> <urn:object> .
> <urn:subject> <urn:predicate> "object" .
> <urn:subject> <urn:predicate> "object"@lang .
> <urn:subject> <urn:predicate> _:X .
> _:X <urn:predicate> <urn:object> .
> _:X <urn:predicate> "object" .
> _:X <urn:predicate> "object"@lang .
> _:X <urn:predicate> _:Y .
>
> These cases can be trivially mapped into HTML5 microdata as:
>
> <div item>
> <link itemprop="about" href="urn:subject">
> <link itemprop="urn:predicate" href="urn:object">
> </div>
>
> <div item>
> <link itemprop="about" href="urn:subject">
> <meta itemprop="urn:predicate" content="object">
> </div>
>
> <div item>
> <link itemprop="about" href="urn:subject">
> <meta itemprop="urn:predicate" content="object" lang="lang">
> </div>
>
> <div item>
> <link itemprop="about" href="urn:subject">
> <meta itemprop="urn:predicate" item id="X">
> </div>
>
> <link subject="X" itemprop="urn:predicate" href="urn:object">
>
> <meta subject="X" itemprop="urn:predicate" content="object">
>
> <meta subject="X" itemprop="urn:predicate" content="object" lang="lang">
>
> <meta subject="X" itemprop="urn:predicate" item id="Y">
On Fri, 15 May 2009, Philip Taylor wrote:
>
> Hmm, I think I'm wrong here. 'id' has to be unique, which means this
> pattern won't work if _:X is the object for triples with two different
> subjects.
Right; this would require the "include pattern" idea from Microformats,
which I have some ideas on (using a <ref itemprop="" href=""> element),
but I think we should wait to see how microdata fares as is first (none of
the use cases for microdata actually needed this).
On Mon, 18 May 2009, Eduard Pascual wrote:
>
> Ian's initial message goes step by step through the creation of this new
> syntax; but does *not* mention at all *why* it was being created on the
> first place. The insight into the choices taken is indeed a good think,
> and I thank Ian for it; but he omitted to provide insight into the first
> choice taken: discarding the multiple options already available (not
> only Microformats and RDFa, but also other less discussed ones such as
> eRDF, EASE, etc). Sure, there has been a lot of discussion on this
> topic; and it's possible that the choice was taken as part of such
> discussions. In any case, I think Ian should have clearly stated the
> reasons to build a brand new solution when many others have been out for
> a while and users have been able to try and test them.
I didn't list every solution I considered (such as eRDF and EASE) because
those solutions were already so widely criticised by the supporters of
technologies like RDFa and Microformats that I didn't really think there
was any point going into more detail about those.
eRDF's main problem is the use of class=""; like Microformats, this causes
confusion with authors.
RDF EASE separates the semantics from the data, which in general I believe
would lead to a very brittle system.
Both also suffer from many of the indirection problems inherent of any
prefix-based system.
However, like Microformats, nothing prevents either of these systems from
being used with HTML5 today, as far as I can tell. Unlike RDFa, they do
not require any changes to the underlying markup language. If they are
better than microdata, then they will see adoption, and we can drop
microdata from the HTML5 draft.
> Ok, the syntax is simpler for a subset of the use cases; but it leaves
> entirely out the rest of use cases.
As far as I'm aware, microdata handles all the use cases that were
mentioned that are also solved by RDFa and Microformats (as well as
solving a number of other use cases that the other two don't solve, such
as the drag-and-drop cases). If there are use cases that should be
addressed that I did not address, please raise them.
> *extensibility*. And, with over two decades between versions of the
> specs, this is a strong requirement: if a problem is noticed after HTML5
> becomes "the standard", it's essential to be able to solve it without
> waiting 10 or 20 years for HTML6 to come out. In addition, your alleged
> "simplified" data model is actually an over-complication, as it is
> defined in the form of restrictions and/or limitations over RDF's model.
> Try to explain what can be represented in RDF, and what can be
> represented with microdata, and you'll see what's simpler.
The only reason there was a long wait between HTML4 and HTML5 is that HTML
was abandoned by the W3C. As soon as someone wanted to maintain HTML
again, development resumed. There's no reason to believe it would take 20
years to add a new feature -- it could be done overnight if there was the
will and the need.
> Henri:
> > I consider it an advantage that reverse domains don't suggest that you
> > should try dereferencing identifiers as if they were addresses.
>
> But they still try to look address-like enough. Lots of users will try
> to "reorder" the domain and recover the address behind it (without
> knowing that there isn't a real address behind it), with the obvious
> confussion when they fail at all attempts (since something that doesn't
> exist can't be recovered).
I don't see any reason to believe this is the case. Do people do this with
Java identifiers? I've never heard of anyone trying to do that.
On Fri, 15 May 2009, Eduard Pascual wrote:
> On Thu, May 14, 2009 at 10:17 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> >
> > From my cursory study, I think microdata could subsume many of the use
> > cases of both microformats and RDFa.
>
> Maybe. But microformats and RDFa can handle *all* of these cases.
Actually, this isn't true. For example, neither Microformats and RDFa have
a DOM or integration with the drag-and-drop API in HTML5.
> Allright, an API may be a benefit. Most probably it is. However, a
> similar API could have been built from RDFa, or eRDF, or EASE, or any
> other already existing or new solution
As has been discussed, I did consider RDFa, but IMHO it has some fatal
problems that make it inappropriate for text/html. eRDF's use of "class"
is suboptimal, and it hasn't been found especially popular amongst the RDF
community. EASE would be significantly more complicated for user agents to
implement as a DOM API than the other three.
> Now microdata comes out, some drawbacks are highlighted in comparison
> with RDFa (lack of typing,
As far as I can tell, per-instance typing (as opposed to per-class typing,
where all properties of a particular name are implicitly typed) is not a
requirement for any of the use cases that were listed and that I tried to
address. If there are use cases that require per-instance typing, please
do bring them up so that they can be considered.
> inability to depict the full RDF model,
Depicting the RDF model isn't necessary to resolve the use cases that were
brought up; that there is any RDF support at all is opportunistic rather
than a design goal. (That is, adding RDF support was simple enough to do
that I figured I might as well, rather than something that's key to the
use cases listed.)
> Reversed domains are as ugly as CURIEs (but at least CURIEs resolve to
> something useful, while reversed domains often don't resolve at all)
As Henri has pointed out, not resolving is actually a benefit; there has
been ample evidence that making identifiers resolve causes more problems
than it solves. For example:
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
> what does microdata provide to make up for its drawbacks?
A simpler, more usable syntax; a DOM API; and integration with the HTML5
drag-and-drop model, amongst other things that other have listed.
> Of course. I'm willing to experiment. I experimented with RDFa some
> time ago and found it unsuitable for my needs. I have taken a look at
> microdata and it isn't any more suitable.
I will look carefully at your proposal shortly; hopefully that thread will
clarify what your needs are.
> Technical problems have already been cited. Here's a summary, just
> review the thread for further details on each:
>
> - Microdata can't handle non-string objects: even if I use the <time>
> element to mark up a date with microdata, it will be taken as a string
> rather than as a date. Since tools may be relying on explicit typing for
> some tasks, this limitation renders microdata less usable than RDFa.
What are the use cases for which this matters? As far as I can tell,
typing was not necessary for any of the use cases that were brought up,
which are listed in the e-mails cited here:
http://lists.w3.org/Archives/Public/public-html/2009May/0207.html
For example, consider the calendar use cases. The output format is vEvent,
and the typing information doesn't affect the conversion.
> - Microdata is an entirely new syntax. It requires implementation and
> deployment of consumers before it can be used at all; while RDFa has
> already gone through this step. (This is not a very serious problem, but
> is a cost to be considered.)
I think that relative to the long term goals here, no format has really
gotten significant traction. RDFa and Microformats have the most usage,
but even they see virtually no usage when examined at the scale of the Web
as a whole.
This isn't a criticism of RDFa or Microformats; but I do think it is naive
to claim that RDFa has "gone through the implementation and deployment
stage". Note that implementation of microdata fetaures has been shown to
be basically trivial -- two people implemented basically the entire
microdata model within 24 hours of hearing of the proposal (in fact one of
them did it between when I checked in the spec text and went to bed, and
when I woke up the next morning).
> - Microdata can't represent the full RDF data model (while RDFa can):
> some complex structures are just not expressable with microdata.
As far as I can tell none of the use cases actually need RDF at all, let
alone the more complex features of RDF, so this doesn't seem to be a
problem in practice.
(The only exception might be the validation use case, for which one
possible solution is reusing RDFS/OWL, but personally my stance on
validation is that schemas aren't a good solution and hard-coded tools are
better, so I'm not really convinced of even this exception.)
> - Microdata inherits all of the flaws from RDFa (except for the use of
> CURIEs, which some people here consider an inconvenient). For example,
> marking up a list of items requires lots of redundant code.
Yes, it would be nice to find a better solution for this that doesn't
involve external resources or Selectors.
> - Microdata relies on reversed domains. While some people argue these to
> be better than CURIEs, they are equally horrendous for the average user,
> and have the additional disadvantage that they don't map to anything
> useful (if they map to something at all), while CURIEs map to the
> descriptions and/or definitions of what they represent.
Not mapping to anything is an intentional design decision; I do not
believe that having identifiers be resolvable as URIs is good design. I do
not think that reversed-DNS identifiers (which are basically just opaque
strings with dots in them) are anywhere near as horrendous as prefix-based
solutions or even straight URIs, though straight URIs are supported in
microdata if that is preferred.
On Fri, 15 May 2009, Shelley Powers wrote:
>
> You don't have to take my word for it -- check out Philip's testing demo
> for microdata. You get triples with the following:
>
> http://www.w3.org/1999/xhtml/custom#com.damowmow.cat
>
> http://philip.html5.org/demos/microdata/demo.html#output_ntriples
>
> Not only do you face problems with link rot, you also face a significant
> amount of confusion, as people look at that and go, "What the hell is
> that?"
If anyone has a better suggestion for how to map reversed DNS names to RDF
identifiers, I'd be glad to update the spec. (The only requirement is that
it not be possible for two different conforming microdata identifiers to
result in the same RDF identifier -- to this end, for instance, the
"http://www.w3.org/1999/xhtml/custom#" prefix is not conforming in any
itemprop="" names in HTML5.)
The current mapping is just there because I couldn't find a better
solution. RDF doesn't seem to support non-URI identifiers.
> But hey, you've given me another idea. I think I'll create my own
> vocabulary items, with the reversed DNS
> http://www.w3.org/1999/xhtml/custom#com.sun.*. No, maybe
> http://www.w3.org/1999/xhtml/custom#com.opera.*. Nah, how about
> http://www.w3.org/1999/xhtml/custom#com.microsoft.*. Yeah, that's cool.
> And there is no mechanism is place to prevent this, because unlike
> "regular" URIs, where the domain is actually controlled by specific
> entity, you've created the world famous W3C fudge pot. Anything goes.
What stops you from creating http://sun.com/* identifiers?
Reversed DNS names use the exact same registration mechanism as URIs.
> But Foobar takes a dive in the dot com pool, and foobar.com gets taken
> over by a porn establishment. Yeah, I can't wait for people to explain
> that one to the boss. Just because it doesn't link, won't mean it won't
> end up on Twitter as a big, huge joke.
This seems to be a problem for URIs far more than reversed DNS names...
On Fri, 15 May 2009, Manu Sporny wrote:
> Kristof Zelechovski wrote:
> >
> > (WHATWG wants HTML documents to be readable 1000 years from now.)
>
> Is that really a requirement?
I believe Kristof is refering to my personal desire to write documentation
that describes the Web infrastructure in enough detail that a software
archeologist 1000 years from now, armed only with the spec and an archive
of today's Web content, would be able to write a user agent to render the
Web content as today's browsers do, without having to reverse engineer the
expected behaviour from the content.
> Also, why 1000 years, that seems a bit arbitrary? =P
The number is arbitrary; I just mean a sufficiently long time that it is
plausible that there would be no way to actually run today's software.
On Thu, 14 May 2009, Eduard Pascual wrote:
>
> But *why* restrict literals to strings?? Being unable to state that
> "2009-05-14" is a date makes that value completely useless
This is demonstrably false -- vEvent blobs in HTML5 microdata have a
defined mapping to raw iCalendar data, including roundtripping of dates,
despite their being treated as strings.
> it would only be useful on contexts where a date is expected (bascially,
> because it is a date), but it can't be used on such contexts because the
> tool retrieving the value has no hint about it being a date. Same is
> true for integers, prices (a.k.a. decimals plus a currency symbol),
> geographic coordinates, iguana descriptions, and so on.
You can distinguish all of those by inspection.
In any case, why would you put a price in the same field as a date? If you
use stringly typed _fields_, rather than _values_, you can sidestep the
entire issue cleanly.
On Thu, 14 May 2009, Jonas Sicking wrote:
>
> Some of the improvement suggestions that I have heard that sounds
> interesting, though possibly for the next version of microdata.
>
> * Support for specifying a machine-readable value, such as for dates,
> colors, numbers, etc.
I expect we will add support for these based on demand, the same way we
added <time> in the first place.
> I even wonder it would allow replacing the <time> element with a
> standardized microformat, such as:
>
> Christmas is going down on <span item="w3c.time"
> itemvalue="12-25-2009">The 25th day of December<span>!
I don't really understand how that would be better than dedicated
elements.
> * Support for tabular data.
This would be nice if we can find a way to do it that doesn't put undue
burdens on simple implementations. (e.g. I would imagine that while a
microdata implementation today can be a few hundred lines total, adding
support for the table model could easily double that.)
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 9 June 2009 01:40:54 UTC