W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2009

[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

From: <bugzilla@wiggum.w3.org>
Date: Wed, 28 Oct 2009 06:26:10 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1N31z0-0002fo-Nn@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8107





--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch>  2009-10-28 06:26:10 ---
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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 28 October 2009 06:26:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 28 October 2009 06:26:21 GMT