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 13007 - should (resolved) itemid be unique within a document?
Summary: should (resolved) itemid be unique within a document?
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML Microdata (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-21 13:17 UTC by contributor
Modified: 2011-08-04 05:05 UTC (History)
7 users (show)

See Also:


Attachments

Description contributor 2011-06-21 13:17:28 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html
Multipage: http://www.whatwg.org/C#global-identifier
Complete: http://www.whatwg.org/c#global-identifier

Comment:
should (resolved) itemid be unique within a document?

Posted from: 83.218.67.122
User agent: Opera/9.80 (X11; Linux x86_64; U; Edition Next; en) Presto/2.8.165 Version/11.50
Comment 1 Philip Jägenstedt 2011-06-21 13:22:11 UTC
Regarding an example from https://twitter.com/#!/manusporny/status/82925452498452480

<span itemscope itemtype="http://schema.org/WebPage" itemID="#foo">
   <span itemprop="name">My Website and Blog</span>
</span>

<span itemscope itemtype="http://schema.org/BlogPost" itemID="#foo"> 
   <a itemprop="url" href="http://example.org/post-4">permalink</span>
</span>

The spec talks about itemid as a global identifier, but does not require that the resolved itemid be unique within a document. Of course it should be globally unique, but all a validator can usefully check is that it's unique within the document.

Perhaps wording similar to what's in http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#concept-id would be appropriate?
Comment 2 Manu Sporny 2011-06-21 14:09:33 UTC
Fixed example: 

<span itemid="#foo" itemscope itemtype="http://schema.org/WebPage">
   <span itemprop="name">My Website and Blog</span>
</span>

<span itemid="#foo" itemscope itemtype="http://schema.org/BlogPost"> 
   <a itemprop="url" href="http://example.org/post-4">permalink</a>
</span>
Comment 3 Philip Jägenstedt 2011-06-21 14:22:26 UTC
Did you change anything except capitalization?
Comment 4 Philip Jägenstedt 2011-06-21 14:23:39 UTC
Offtopic: It might be worth asking on the schema.org mailing list if itemid actually means anything when used with their vocabulary.
Comment 5 Manu Sporny 2011-06-21 15:06:06 UTC
(In reply to comment #3)
> Did you change anything except capitalization?

Fixed a mismatched <a> element in the second span.
Comment 6 Manu Sporny 2011-06-21 15:09:44 UTC
(In reply to comment #4)
> Offtopic: It might be worth asking on the schema.org mailing list if itemid
> actually means anything when used with their vocabulary.

The issue has more to do with expected behavior than schema.org. I just used them as an example.

When you use the same @itemid on the page, is the expected behavior that:

1) All properties for the same @itemid are merged with two separate items on the page.
2) All properties and types for the same @itemid are merged.
3) What happens when somebody does a getItems() and uses one of the itemtypes - are all properties returned?

I'll delve down deeper into the spec later on tonight, but this was surprising to me. With RDFa and RDF in general, all things w/ the same "@itemid" would be merged into a single object with multiple types when retrieved via the RDFa API.
Comment 7 Tab Atkins Jr. 2011-06-21 16:03:30 UTC
I think you've gotten yourself confused, Philip.  Two Microdata items with the same @itemid are simply referring to the same abstract thing which exists independently from the document.  It is not comparable with @id, which names a particular element in the document.  You are just, say, creating two Microdata items which both provide information about the same book.
Comment 8 Manu Sporny 2011-06-21 16:14:35 UTC
(In reply to comment #7)
> I think you've gotten yourself confused, Philip.  Two Microdata items with the
> same @itemid are simply referring to the same abstract thing which exists
> independently from the document.  It is not comparable with @id, which names a
> particular element in the document.  You are just, say, creating two Microdata
> items which both provide information about the same book.

This doesn't make sense.

If you are asserting that @itemid is used to refer to the same abstract thing, then shouldn't properties associated with that abstract thing be reflected when you retrieve that thing?

That is, if I add properties to "http://example.org/things#foo" in separate parts of a document, when I retrieve an item identified as "http://example.org/things#foo", then I would expect that all properties added to that item would be returned to me.

Why is this not the case?
Comment 9 Tab Atkins Jr. 2011-06-21 16:18:13 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > I think you've gotten yourself confused, Philip.  Two Microdata items with the
> > same @itemid are simply referring to the same abstract thing which exists
> > independently from the document.  It is not comparable with @id, which names a
> > particular element in the document.  You are just, say, creating two Microdata
> > items which both provide information about the same book.
> 
> This doesn't make sense.
> 
> If you are asserting that @itemid is used to refer to the same abstract thing,
> then shouldn't properties associated with that abstract thing be reflected when
> you retrieve that thing?

This is a completely separate issue from what Philip was talking about.

If you want multiple sets of properties to be reflected in a single Microdata item, mark up one of the sets as an item and use @itemref to refer to the rest.  There's no need to do magic coalescing here.
Comment 10 Manu Sporny 2011-06-21 20:39:34 UTC
(In reply to comment #9)
> This is a completely separate issue from what Philip was talking about.

It's related - it's not completely separate. I submitted the original bug to Philip wondering how someone could specify that something is both a Web Page and a Blog.

> If you want multiple sets of properties to be reflected in a single Microdata
> item, mark up one of the sets as an item and use @itemref to refer to the rest.
> There's no need to do magic coalescing here.

If you do this:

<span itemref="foo" itemscope itemtype="http://schema.org/WebPage">
   <span itemprop="name">My Website and Blog</span>
</span>

<span itemref="foo" itemscope itemtype="http://schema.org/BlogPost"> 
   <a itemprop="url" href="http://example.org/post-4">permalink</a>
</span>

Then this is the JSON result per Philip's implementation:

{
  "items": [
    {
      "type": "http://schema.org/WebPage",
      "properties": {
        "name": [
          "My Website and Blog"
        ]
      }
    },
    {
      "type": "http://schema.org/Blog",
      "properties": {
        "url": [
          "http://example.org/blog"
        ]
      }
    }
  ]
}

Not only that, but the RDF is strange as well. At least with @itemid, the RDF seems sensible, but the JSON is strange.

What am I missing?
Comment 11 Tab Atkins Jr. 2011-06-22 00:47:34 UTC
(In reply to comment #10)
> If you do this:
> 
> <span itemref="foo" itemscope itemtype="http://schema.org/WebPage">
>    <span itemprop="name">My Website and Blog</span>
> </span>
> 
> <span itemref="foo" itemscope itemtype="http://schema.org/BlogPost"> 
>    <a itemprop="url" href="http://example.org/post-4">permalink</a>
> </span>

You're using @itemref wrong.  @itemref takes a list of ids that should also be trawled for properties.

<span itemscope itemtype="http://schema.org/WebPage" itemref="foo">
  <span itemprop=name>My Website and Blog</span>
</span>

<span id=foo>
  <a itemprop=url href="http://example.org/post-4">permalink</a>
</span>
 
This produces a single Microdata item with 'name' and 'url' properties, of type "http://schema.org/WebPage".

If you want two items with different types but the same values, do something like this:

<meta itemscope itemtype="http://schema.org/WebPage" itemref="foo">
<meta itemscope itemtype="http://schema.org/BlogPost" itemref="foo">
<span id=foo>
  <span itemprop=name>My Website and Blog</span>
  <a itemprop=url href="http://example.org/post-4">permalink</a>
</span>

This will produce two Microdata items, one of each type, both carrying the same 'name' and 'url' properties.  You can give either or both of them an @itemid as well, if you need to.
Comment 12 Manu Sporny 2011-06-22 02:41:32 UTC
(In reply to comment #11)
> If you want two items with different types but the same values, do something
> like this:
> 
> <meta itemscope itemtype="http://schema.org/WebPage" itemref="foo">
> <meta itemscope itemtype="http://schema.org/BlogPost" itemref="foo">
> <span id=foo>
>   <span itemprop=name>My Website and Blog</span>
>   <a itemprop=url href="http://example.org/post-4">permalink</a>
> </span>
> 
> This will produce two Microdata items, one of each type, both carrying the same
> 'name' and 'url' properties.  You can give either or both of them an @itemid as
> well, if you need to.

That's better, but still not ideal. As I stated above, I'd like to specify that something (one item) has two types - Blog and WebPage. It's fairly simple to do in RDFa 1.1:

<div vocab="http://schema.org/" about="#myblog" typeof="WebPage Blog">
  <span property="name">My Website and Blog</span>
  <a rel="url" href="http://example.org/post-4">permalink</a>
</div>

which results in the following triples:

<#myblog> rdf:type <http://schema.org/Blog> .
<#myblog> rdf:type <http://schema.org/WebPage> .
<#myblog> <http://schema.org/name> "My Website and Blog" .
<#myblog> <http://schema.org/url> <http://example.org/post-4> .

It is /possible/ to do this in Microdata, but the RDF is the only part that is correct. If you use @itemref, you get one item with the properties listed above. However, the JSON output lists two items, and that's inconsistent and strange. The guys at Google that work on schema.org seem to be telling people to do the thing that gives you the proper RDF, but when people go to extract this data using the Microdata API, they may be very surprised that all of the data isn't there:

http://groups.google.com/group/schemaorg-discussion/msg/011c3a8ddd146a9a

I am asserting that the data returned in the RDF and the data returned by the Microdata DOM API (JSON) should not surprise developers like this. This is because Google, Microsoft and Yahoo Search are going to see one thing and applications that use the DOM are going to see something else. It also forces developers to have to write extra code to map between the JSON and the RDF representations of the same data in Microdata.
Comment 13 Philip Jägenstedt 2011-06-22 08:16:34 UTC
(In reply to comment #7)
> I think you've gotten yourself confused, Philip.  Two Microdata items with the
> same @itemid are simply referring to the same abstract thing which exists
> independently from the document.  It is not comparable with @id, which names a
> particular element in the document.  You are just, say, creating two Microdata
> items which both provide information about the same book.

This may very well be the case. Calling it "global identifier of an item" certainly makes it sounds like it's an identifier of the item, rather than an identifier of an abstract thing which exists independently of the item.
Comment 14 Philip Jägenstedt 2011-06-22 08:17:33 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > Offtopic: It might be worth asking on the schema.org mailing list if itemid
> > actually means anything when used with their vocabulary.
> 
> The issue has more to do with expected behavior than schema.org. I just used
> them as an example.
> 
> When you use the same @itemid on the page, is the expected behavior that:
> 
> 1) All properties for the same @itemid are merged with two separate items on
> the page.
> 2) All properties and types for the same @itemid are merged.
> 3) What happens when somebody does a getItems() and uses one of the itemtypes -
> are all properties returned?
> 
> I'll delve down deeper into the spec later on tonight, but this was surprising
> to me. With RDFa and RDF in general, all things w/ the same "@itemid" would be
> merged into a single object with multiple types when retrieved via the RDFa
> API.

Manu, can you file a separate bug for this?
Comment 15 Philip Jägenstedt 2011-06-22 08:24:31 UTC
(In reply to comment #4)
> Offtopic: It might be worth asking on the schema.org mailing list if itemid
> actually means anything when used with their vocabulary.

Offtopic: http://groups.google.com/group/schemaorg-discussion/browse_thread/thread/62117670d187559e
Comment 16 Ian 'Hixie' Hickson 2011-07-07 22:59:02 UTC
Comment 7 is correct. itemid="" is just a way to give an identifier to the item; it's up to the vocabulary to define whether multiple items with the same global identifier (whether on the same page or on different pages) make sense, are or are not conforming, and what the processing rules for that vocabulary are with respect to handling the case of multiple items with the same ID.

I've clarified the spec to this effect.

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: see diff given below
Rationale: Concurred with reporter that it wasn't clear.
Comment 17 contributor 2011-07-07 23:00:04 UTC
Checked in as WHATWG revision r6279.
Check-in comment: Clarify the role of vocab specifications w.r.t. itemid=''.
http://html5.org/tools/web-apps-tracker?from=6278&to=6279
Comment 18 Michael[tm] Smith 2011-08-04 05:05:51 UTC
mass-move component to LC1