12713 2011-05-20 09:44:15 +0000 Mapping microdata in RDF (section 5.2) 2011-08-26 19:16:40 +0000 1 1 1 Unclassified HTML WG LC1 HTML Microdata (editor: Ian Hickson) unspecified PC Windows XP RESOLVED WONTFIX TrackerIssue P2 normal --- 1 raphael.troncy ian a.kuckartz ayg eoconnor giovanni.tummarello ian mike philipj public-html-admin public-html-wg-issue-tracking rubys public-html-bugzilla oldest_to_newest 48658 0 raphael.troncy 2011-05-20 09:44:15 +0000 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 predicate be s 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 Street name 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 type 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 type 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 type. 6.1.5.2 should say: If the last character of s 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 s. 48659 1 philipj 2011-05-20 10:58:59 +0000 It seems to me that the suggested scheme would easily conflict with other URIs... 48985 2 ian 2011-05-31 23:20:11 +0000 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. 49333 3 ian 2011-06-08 19:57:54 +0000 *** Bug 12891 has been marked as a duplicate of this bug. *** 52921 4 mike 2011-08-04 05:05:22 +0000 mass-move component to LC1 54380 5 raphael.troncy 2011-08-08 14:26:51 +0000 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. 55896 6 rubys 2011-08-26 19:16:40 +0000 Tracker issue opened: http://www.w3.org/html/wg/tracker/issues/171