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 13466 - URL generation algorithm for RDF properties is problematic
Summary: URL generation algorithm for RDF properties is problematic
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML Microdata (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Linux
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on: 13314
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-30 15:13 UTC by Manu Sporny
Modified: 2011-08-11 22:31 UTC (History)
7 users (show)

See Also:


Attachments

Description Manu Sporny 2011-07-30 15:13:05 UTC
This feedback is filed as a personal comment and is not intended to be any sort
of official feedback from any standards working group.

As an example, the Microdata URL generation algorithm currently generates RDF triples with predicates of the following form:

<http://www.w3.org/1999/xhtml/microdata#http://schema.org/Person%23:name>

where-as an RDF system would ideally expect the following URL:

<http://schema.org/name>

These sorts of URLs are generated for short-form properties specified using @itemprop. Using a full IRI "resolves" the issue, but the point is that the URL above is foreign and nearly useless to RDF systems for the following reasons:

1. There is some sort of strange hierarchical layout to the URL meaning that a "given-name" value would not map to the same URL when used in an hcard (hcard.n.given-name) and an hcard used inside a (hrecipe.author.hcard.n.given-name). The path to the item is encoded in the URL, which is bad. A good RDF application would just have given-name always map to the same vocabulary URL.

2. Microdata mints new, different URLs for all RDF properties that currently have URLs. That is, if you want to use the RDF URLs, you must use full IRIs everywhere. Authors are expected to understand that the RDF URLs that you are generating will be different from the ones used by other RDF systems thus creating a complexity at the application layer. Now, application authors depending on this data in RDF must introduce complexity into their system to understand that any URL ending in "given-name" with "microdata" somewhere in the URL really maps to <http://schema.org/name> or <http://schema.org/Person/name> .

3. The URLs are hard to read, which people building applications on top of Microdata, Microformats or RDFa tend to need to do from time to time.

Change the RDF generation algorithm in Microdata to generate the following URL for the example given above:

<http://schema.org/name>

A name is a name - don't have a different name property for People, Places, Events, Things, etc.

You could change the RDF property URL generation algorithm to the following:

1. Get the Items @itemtype value (e.g. http://schema.org/Person). 
2. Find the greatest offset of '/' or '#' in the URL. 
3. Replace everything after the greatest offset with the short name in @itemprop.

This would generate much nicer, easy to read, URLs for the RDF that is generated from Microdata.
Comment 1 Danny Ayers 2011-07-30 19:04:08 UTC
This is much broader than just RDF, any sane representation system (e.g. a Javascript mapping or an SQL table) will expect the same ID (/name/IRI) for the same property, whatever the context. Right now it's just bad modeling.

I believe the style of URI generation Manu suggests is the cleanest solution.
Comment 2 Philip Jägenstedt 2011-07-30 22:25:18 UTC
Marked as blocking bug 13314, where you supported dropping the algorithm entirely. This is most likely what will happen unless someone speaks up for it.
Comment 3 Philip Jägenstedt 2011-07-30 22:26:21 UTC
s/blocking/depending on/
Comment 4 Philip Jägenstedt 2011-07-30 22:28:39 UTC
The suggested algorithm is also problematic, as discussed in https://plus.google.com/115239936584020095918/posts/N2Wfiku19SS
Comment 5 Michael[tm] Smith 2011-08-04 05:05:39 UTC
mass-move component to LC1
Comment 6 Manu Sporny 2011-08-09 00:14:17 UTC
The suggested algorithm is problematic because it mucks around with http://n.whatwg.org/work ? Is that the concern.

How may people are using that vocabulary and namespace? If there are hardly any (which I assume that there are), change the spec so that that one namespace doesn't make all other vocabulary IRIs suffer.
Comment 7 Ian 'Hixie' Hickson 2011-08-11 22:31:30 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: no longer relevant