On Sun, 29 Nov 2009 12:46:16 +0100, Tim van Oostrom <t...@depulz.nl> wrote:
Philip Jägenstedt wrote:
On Thu, 26 Nov 2009 22:30:41 +0100, Tim van Oostrom <t...@depulz.nl>
wrote:
Hi, I made a forumpost :
http://forums.whatwg.org/viewtopic.php?t=4176, concerning a possible
"microdata specification bug" and a bug in the james.html5.org
microdata extractor.
Comes down to <link/> and <meta/> elements possibly being unfit for
use with the itemscope attribute.
I made an example in the forum post with some nice ubb formatting .
There are some other issues with <link> and <meta> you might want to
review first: [1]
Ok
Your second example was:
<div itemtype="http://url.to/geoVocab#country"; itemscope>
<span itemprop="http://xmlns.com/foaf/spec/index.rdf#name";
lang="cn">中華人民共和國</span>
<span itemprop="http://xmlns.com/foaf/spec/index.rdf#name";
lang="en">China</span>
<link itemprop="http://url.to/city"; href="http://url.to/shanghai";
itemscope itemref="city-shanghai" />
<div id="city-shanghai">
<span
itemprop="http://xmlns.com/foaf/spec/index.rdf#name";>Shanghai</span>
<span itemprop="http://url.to/demoVocab#population";>14.61 million
people</span>
<span itemprop="http://url.to/physicsVocab#time";
datetime="2009-11-26 11:43">11:43 pm (CT)</span>
</div>
</div>
By using itemprop+itemscope, you're saying that the property is itself
an item. Also specifying href="http://url.to/shanghai"; does nothing.
I also pointed that out in my forumpost.
I probably didn't read it all closely enough to see which parts were
misunderstandings and which parts were intentionally testing the limits of
the spec, sorry if I hit you on the head with things you already knew.
<link>, <meta> and any other void elements are usually the wrong choice
for itemprop+itemscope because they don't have child elements, so
itemref is the only way to add properties.
Yes, see forumpost. Shouldn't this be noted in the Spec then ? (maybe i
read over it)
Yes, the spec certainly needs some notes on how to use <link> and <meta>.
What you've accidentally done above is add the 3 properties of Shanghai
to both the top-level item and the sub-item, see [2] for details.
Well, i did it in full awareness, i interpreted the itemref attribute
like this. But if it can't be used this way, isn't this a setback on the
flexibility of itemref? Or was it intended this way.
According to this an "itemref" attribute can never be added to an "item"
within an itemscope of another "item" without the crawled prop/val pairs
also applying to the ancestors itemscope.
Ah, I think you've found the root of the problem. By allowing a property
to be part of several items at once, we get different kinds of strange
problems. Except from messing up your example, it seems it is the real
cause for the infinite recursion bug I wrote about in [1]. Then I was so
focused on the recursion that I suggested a rather complex solution to
detect loops in the microdata, when it seems it could be solved simply be
making sure that a property belongs to only 1 item. Detailed suggestion
below.
[snip Amanda example]
[snip most of what Shanghai is to China]
Assigning "unique" properties to Subjects for RDF's sake doesn't seem
like a good idea to me.
Ofcourse i can make other, more sensible, html markup but the whole
point of a solid annotating language is that i can apply it to my
existing markup without changing it.
Hehe, I wasn't suggesting a unique predicate for each combination of
country and city, just trying to sort out what is the itemprop and what is
the itemtype in your example. If you want RDF I suppose you have to find
some vocabulary that has a predicate that makes sense as China *predicate*
Shanghai.
If <http://url.to/shanghai> is a global identifier for Shanghai you
should use itemid.
Correct, but the href="" is ignored in that example. If it only
concerned a property i'd use :
<link itemprop="http://url.to/city"; href="http://url.to/shanghai"; />
and it would be valid. I used it to show my point about <link/> and
itemscope, see forumpost.
In this example, I really don't see why you would use <link> to make a
sub-item to begin with. Perhaps we should make itemscope on <link> and
<meta> invalid in order to warn people of the problem?
I don't know what <http://url.to/physicsVocab#time> is, but note that
an exact time isn't very useful without a timezone, so I added the PRC
timezone for you. I'll also note that using traditional Chinese for the
full name of the PRC is an odd choice, so I changed it to simplified
Chinese above.
Marking up the population as "14.61 million people" isn't terribly
helpful if you want a computer to be able to find the city with the
biggest population among several cities, unless your vocabulary defines
how to parse "14.61 million people" into a number, which would be
strange. In any case this is hidden metadata unless you want 14610000
or some other easily machine-parsable representation to be visible in
the page rendering.
Ok but using content="" on a span, is that valid ? Your suggestion in
[1] would be nicer. But i prefer the use of <link/> and <meta/> elements.
Oops, my suggestion is broken, I mean to write:
<span hidden itemprop="http://url.to/demoVocab#population";>14610000</span>
Finally, I think <http://xmlns.com/foaf/spec/index.rdf#name> should be
<http://xmlns.com/foaf/0.1/name>. If you're going to use existing
vocabularies like FOAF and want your data to be play nice with the RDF
world, make sure to check that the result of the RDF extraction
algorithm [3] is what you intended.
This remains unclear to me. For example : http://xmlns.com/foaf/0.1/name
redirects to an html page but : http://purl.org/dc/terms/title redirects
to an .rdf file. For readability, wouldn't
http://xmlns.com/foaf/spec/#term_name and
http://dublincore.org/documents/dcmi-terms/#elements-title be better ?
If i dereference these url's i find the information i want in one stop.
If you want to reuse an RDF vocabulary you have to use byte-by-byte the
exact same URIs. I agree that finding the correct URI is quite difficult
because treating them as a URL and looking them up in a browser will often
redirect you. I got <http://xmlns.com/foaf/0.1/name> by looking at the
namespace declaration used for foaf and appending "name".
In particular, you probably want to use itemid where possible and make
sure that all your URIs are exactly correct. Personally, though, unless
I could reuse existing vocabularies for every single item and property,
I would only use a full URI for itemtype and point that to a vocabulary
that defines what simpler property names like "name" and "city" mean
and how to convert the vocabulary to RDF.
[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024116.html
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html#rdf
Now, back to the problem of one property, multiple items. The algorithm
for finding the properties of an item [2] is an attempt at optimizing the
search for properties starting at an item element. I think we should
replace this algorithm with an algorithm for finding the item of a
property. This was previously the case with the spec before the itemref
mechanism. I would suggest something along these lines:
1. let current be the element with the itemprop attribute
2. if current has an ID, for each element e in document order:
2.1. if e has an itemref attribute:
2.1.1. split the value of that itemref attribute on spaces. for each
resulting token, ID:
2.1.1.1. if ID equals the ID of current, return e
3. reaching this step indicates that the item wasn't found via itemref on
this element
4. let parent be the parent element of current
5. if parent is null, return null
6. if parent has the itemscope attribute, return parent
7. otherwise, let current be parent and jump to step 2.
This algorithm will find the parent item of a property, if there is one.
itemref'ing takes precedence over "parent-child linking", so in Tim's
example the properties of Shanghai would be applied to only the Shanghai
sub-item. I'm not convinced writing markup like that is a good idea, but
at least this way it has sane processing. HTMLPropertiesCollection on any
given element would simply match all elements in the document for which
the the algorithm returns that very element. It should be invalid for
there to be any elements in the document with itemprop where this
algorithm returns null or the element itself.
I will try implementing this algorithm in MicrodataJS [3] and see if it
works OK. While it may look less efficient than the current algorithm,
consider that a browser won't implement either algorithm as writting, only
act as if they did. The expensive step of going through all elements with
itemref attributes is actually no more expensive than e.g.
document.querySelector('.classname') if implemented natively.
[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024095.html
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item
[3] http://gitorious.org/microdatajs
--
Philip Jägenstedt
