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 8107 - I dont think that itemid should be prohibited if there is no itemtype. Several of the use cases would work fine with an id but no type
Summary: I dont think that itemid should be prohibited if there is no itemtype. Seve...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords: NE
Depends on:
Blocks:
 
Reported: 2009-10-28 01:34 UTC by contributor
Modified: 2010-10-04 14:48 UTC (History)
6 users (show)

See Also:


Attachments

Description contributor 2009-10-28 01:34:17 UTC
Section: http://www.whatwg.org/specs/web-apps/current-work/#items

Comment:
I dont think that itemid should be prohibited if there is no itemtype.   Several of the use cases would work fine with an id but no type

Posted from: 64.81.73.241
Comment 1 Ian 'Hixie' Hickson 2009-10-28 02:15:59 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: Could you elaborate? Which use cases? How would you know how the item's global identifier was to be interpreted without a vocabulary to define that?
Comment 2 John Giannandrea 2009-10-28 05:27:40 UTC
Types and Schemas (properties) need vocabularies, simple identifiers do not.  So if I wanted to author a web page about the Eiffel Tower, I could use this itemid  http://dbpedia.org/resource/Eiffel_Tower even though I dont know what kind of thing it is (a structure, a monument, a location?)

Services to give strong URIs for human concepts already exist, like http://lookup.dbpedia.org/query.aspx?q=eifel

People often link in HTML to a wikipedia page for example.  They know what the item on the page corresponds to, even though they may not have any structured data for it in the DOM yet.

The restriction that you need to know the type to specify a useful itemid seems overly proscriptive and not in the spirit of HTML markup.
Comment 3 Ian 'Hixie' Hickson 2009-10-28 06:26:10 UTC
If you were using a vocabulary about structures, you could use have that vocabulary define that the URLs all identify structures, maybe the structure that is most prominently referenced on the page that the URL dereferences to. Then, using http://dbpedia.org/resource/Eiffel_Tower would make sense.

If you were using a vocabulary about licensing works, you could have that vocabulary define that the URLs all identify works, specifically, the works that the URLs dereference to. Then, using http://dbpedia.org/resource/Eiffel_Tower wouldn't be talking about the Eiffel tower, but about the Web page on the dbpedia.org server's port 80, as found when using the method GET in the HTTP protocol, giving the path "/resource/Eiffel_Tower".

However, in the absence of a vocabualry to give sense to the global identifier, how would you know what the URL meant? How would you know if it was talking about the Web page, a real-world entity referenced on the Web page, the URL itself, a term, or something else?

If we could define a default interpretation, then I guess we could allow itemid="" to be used without a type — e.g. if we said that it identified the resource given by the URL. But that doesn't seem to be very useful, frankly.
Comment 4 John Giannandrea 2009-10-28 06:33:25 UTC
There is no argument that if the itemtype is defined then the itemid is interpreted in that scope.

My point is that if there is no itemtype then itemid can still be meaningful.

Search engines, like google, can make sense of these "strong identifiers" even if they are in multiple domains or ranges.

Another way of saying this is that there is an implicit vocabulary of "topics" or "concepts" that sites like wikipedia, dbpedia and freebase expose as URIs.  perhaps 1/3 of these topics have no known type.

The reason Im filing the bug is that "we dont know" what people will do and proscribing that one should never use an itemid without an itemtype seems to have no rationale.

Comment 5 Ian 'Hixie' Hickson 2009-10-28 06:45:39 UTC
So what would the itemid="" URL represent if there was no type to define it?
Comment 6 John Giannandrea 2009-10-28 06:53:29 UTC
A unique global identifier for the thing that is the itemscope.

as in "id": "http://dbpedia.org/resource/Eiffel_Tower"  regardless of type.

Comment 7 Ian 'Hixie' Hickson 2009-10-28 07:15:52 UTC
But in the absence of a statement to the contrary, a URL is just a reference to a resource (for HTTP URLs, what we consider a Web page), not a unique identifier. The only thing it identifies is the Web page. It seems very misleading to be encouraging people to use URLs to do something else.
Comment 8 John Giannandrea 2009-10-28 16:57:15 UTC
The RDF folks have a whole dance they do to make the URL stand for the resource and not a web object.   For example http://rdf.freebase.com/ns/en.blade_runner will redirect you to either RDF or an HTML view based on your user agent, and each at different URIs.   The dbpedia URLs cited here likewise are intended to stand for the "thing" (the RDF resource id) and will redirect you to http://dbpedia.org/page/Eiffel_Tower if you dereference them in a browser.

My problem with requiring an itemtype always is that in the absence of any itemprops, you would have to propose some catch all type like itemtype="http://dbpedia.org/concept" which had no schema just to be able to annotate the page with well known itemids.

Comment 9 John Giannandrea 2009-10-28 19:15:52 UTC
Here is a document the linked open data people use to describe the difference between a URI for a resource and a web URL.

http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/#Terminology
Comment 10 John Giannandrea 2009-10-29 04:50:20 UTC
Re-reading comment #7, I think you are questioning if any "resource" can identify anything in the absence of a vocabulary introduced by itemtype.    The whole premise of the Linked Open Data initiative is that you can, that multiple resource URIs mean the same thing and they can be cross referenced between sites.  

For example, all these are the same thing: http://ids.freebaseapps.com/?id=/en/palo_alto

Search engines would love for people to make these links with itemid, even if they didnt have any item data to work with in the page DOM yet.


Comment 11 Ian 'Hixie' Hickson 2009-12-13 15:52:37 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: 

This seems to be an abuse of the URL concept. As I said in comment 3, I understand that one can use URLs to identify something other than what the URL strictly identifies (as defined by the scheme registration and other applicable specifications), but to do so you need to have a specification that says how you are going to interpret the URL. In the absence of such a specification, a URL has no meaning beyond just referencing a Web page (or mailbox, or whatever kind of resource the scheme references). I think we would be encouraging very dubious behaviour if we were to encourage people to use itemid="" to identify non-Web-page concepts or resources without previously defining what they are.

To put this in more concrete terms, consider what happens if two independent Web pages by two different authors both write:

   <div itemscope itemid="http://google.com/">

...in their page. Are they referencing the same thing? One has:

   <div itemscope itemid="http://google.com/">
     <span itemprop="background-color">#FFFFFF</span>
     <span itemprop="price">$0</span>
   </div>

...and the other has:

   <div itemscope itemid="http://google.com/">
     <span itemprop="employee-count">12345</span>
     <span itemprop="price">$500</span>
   </div>

Now are they referencing the same thing? Do we want to encourage search engines to treat them as referencing the same thing?

The whole point of name-value pairs that don't have an itemtype="" is that you can't know what the author meant, because they're using their own proprietary vocabulary. We don't want to encourage any aggregation of that data by third parties. Data should only be aggregated (or used in any way) by third parties like search engines when the data has a declared vocabulary, or when the itemprop="" is a URL. You are welcome to define a URL itemprop="" value that is defined to give a global identifier, assuming you define how that global identifier is to be interpreted, so that e.g. one could have:

   <div itemscope>
     <link itemprop="http://vocabs.example/gid/webpage" href="http://google/com/">
     <span itemprop="background-color">#FFFFFF</span>
     <span itemprop="price">$0</span>
   </div>

   <div itemscope>
     <link itemprop="http://vocabs.example/gid/public-company" href="http://google/com/">
     <span itemprop="employee-count">12345</span>
     <span itemprop="price">$500</span>
   </div>

...(though you still couldn't use the "background-color", "price", and "employee-count" values, since they aren't globally defined), but I think that reusing itemid="" for this purpose without an itemtype="" would lead to mistakes, and thus we should continue to discourage it.