This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The microdata document includes a separate section (section 5.2) on how the microdata information should mapped on RDF. The specification itself seems to be technically correct and implementable. However, the specification also includes design choices for which I would request a change. The issue is the URI-s generated for microdata attribute values in case those values are not absolute URI-s. The current specifications lead to URIs of the form (using the example in the document) http://www.w3.org/1999/xhtml/microdata#http://microformats.org/profile/hcard%23:adr%20street-address Using such URI-s for data originating, in this example from a microformat is unnecessary complicated, and puts an extra strain on any RDF representation of the microdata vocabulary. It would also cast the http://www.w3.org/1999/xhtml/microdata# string as part of that RDF representation for no good technical reason and would make the resulting URI-s either not dereferencable (which is contrary to the requirements set up, for example, in the Linked Open Data community) or would put an extra and unnecessary strain on the w3c server to set up and maintain such dereferencing service. The proposal is to drop the reference to microdata from the URI scheme altogether, yielding, in the case of this specific example, the URI http://microformats.org/profile/hcard#:adr%20street-address The necessary change in the specification is simple. In section 5.2, in the second processing step block, replace 6.5.4 by: 4. Let <em>predicate</em> be <em>s</em> As a further possible simplification, it is also a question why the '#:' scheme is used in the generated URI. While in some cases it may be necessary, the expected majority of cases are of the form, say <span itemscope itemtype="http://microformats.org/profile/hcard"> <span itemprop="street-address">Street name</span> </span> in which case a predicate URI of the form http://microformats.org/profile/hcard#street-address would be much more natural (note the missing ':') character. To achieve that, the following modifications on the specification should be made: Both 4.3 and 5.3 should say: "If the last character of <em>type</em> is not either the U+003A COLON character (:) or the U+0023 NUMBER SIGN character (#), append a U+003A COLON character (:) to type" 5.4 should say: If the last character of <em>type</em> is not either the U+003A COLON character (:) or the U+0023 NUMBER SIGN character (#), append a U+0025 PERCENT SIGN character (%), a U+0032 DIGIT TWO character (2), and a U+0030 DIGIT ZERO character (0) to <em>type</em>. 6.1.5.2 should say: If the last character of <em>s</em> is not either the U+003A COLON character (:) or the U+0023 NUMBER SIGN character (#), append a U+0025 PERCENT SIGN character (%), a U+0032 DIGIT TWO character (2), and a U+0030 DIGIT ZERO character (0) to <em>s</em>.
It seems to me that the suggested scheme would easily conflict with other URIs...
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: It's not "for no good technical reason". It's for a very good technical reason. The reason is that we must ensure that the URLs generated by the algorithm cannot clash with URLs that authors might use, otherwise we end up in a situation where there are multiple redundant ways to express the same RDF and this kind of thing has historically frequently been incorrectly handled by implementations.
*** Bug 12891 has been marked as a duplicate of this bug. ***
mass-move component to LC1
Suggested title: URI-s generated for microdata attribute values Suggested text: The microdata document includes a separate section (section 5.2) on how the microdata information should mapped on RDF. It includes design choices regarding the URI-s generated for microdata attribute values in case those values are not absolute URI-s. The current specifications lead to URIs of the form (using the example in the document) http://www.w3.org/1999/xhtml/microdata#http://microformats.org/profile/hcard%23:adr%20street-address Using such URI-s for data originating, in this example from a microformat is unnecessary complicated, and puts an extra strain on any RDF representation of the microdata vocabulary. It would also cast the http://www.w3.org/1999/xhtml/microdata# string as part of that RDF representation for no good technical reason and would make the resulting URI-s either not dereferencable (which is contrary to the requirements set up, for example, in the Linked Open Data community) or would put an extra and unnecessary strain on the w3c server to set up and maintain such dereferencing service.
Tracker issue opened: http://www.w3.org/html/wg/tracker/issues/171