This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12713 - Mapping microdata in RDF (section 5.2)
Summary: Mapping microdata in RDF (section 5.2)
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML Microdata (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: TrackerIssue
: 12891 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-20 09:44 UTC by Raphael Troncy
Modified: 2011-08-26 19:16 UTC (History)
10 users (show)

See Also:


Attachments

Description Raphael Troncy 2011-05-20 09:44:15 UTC
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>.
Comment 1 Philip Jägenstedt 2011-05-20 10:58:59 UTC
It seems to me that the suggested scheme would easily conflict with other URIs...
Comment 2 Ian 'Hixie' Hickson 2011-05-31 23:20:11 UTC
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.
Comment 3 Ian 'Hixie' Hickson 2011-06-08 19:57:54 UTC
*** Bug 12891 has been marked as a duplicate of this bug. ***
Comment 4 Michael[tm] Smith 2011-08-04 05:05:22 UTC
mass-move component to LC1
Comment 5 Raphael Troncy 2011-08-08 14:26:51 UTC
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.
Comment 6 Sam Ruby 2011-08-26 19:16:40 UTC
Tracker issue opened: http://www.w3.org/html/wg/tracker/issues/171