[Bug 12713] New: Mapping microdata in RDF (section 5.2)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12713

           Summary: Mapping microdata in RDF (section 5.2)
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML Microdata (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: raphael.troncy@eurecom.fr
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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>.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Friday, 20 May 2011 09:44:18 UTC