Recursive Microdata

128 views
Skip to first unread message

黃耀賢 (Yau-Hsien Huang)

unread,
Jul 13, 2011, 6:31:11 PM7/13/11
to schemaorg-...@googlegroups.com
Hello. I think my question is rather about HTML5 and microdata than
schema.org, but I cannot find discussion group about microdata. So,
I question here.

We know itemref makes it possible to fragmentize an entity into parts
and embed these parts into different places of a page. For example,

<div itemscope itemtype="http://schema.org/Person">
    <div itemprop="name">黃耀賢</div>
    <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
        <div>P.O. Box: <span itemprop="postOfficeBoxNumber">241</div>
        <meta itemprop="about" itemscope itemtype="http://schema.org/Person"
                  itemref="md_me" />
    </div>
</div>
<div id="md_me">
    <div itemprop="name"><strong>Y-H Huang</strong></div>
    <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
        <div>P.O. Box: <span itemprop="postOfficeBoxNumber">241</div>
    </div>
</div>

It's a test to microdata itself, and it's supposed that PostalAddress has
an property "about." Then I wonder how it will be if a property refers to its
owner.

<div id="md_me" itemscope itemtype="http://schema.org/Person">
    <div itemprop="name">黃耀賢</div>
    <div itemprop="name">Y-H Huang</div>
    <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
        <div>P.O. Box: <span itemprop="postOfficeBoxNumber">241</div>
        <meta itemprop="about" itemscope itemtype="http://schema.org/Person"
                  itemref="md_me" />
    </div>
</div>

I use http://foolip.org/microdatajs/live/ to view extracted structure in JSON.
It seems... hmm, so itemscopes of "md_me" breaks the reference, right?

/yhh

Philip Jägenstedt

unread,
Jul 13, 2011, 7:12:01 PM7/13/11
to schemaorg-...@googlegroups.com
2011/7/14 黃耀賢 (Yau-Hsien Huang) <g9414002.p...@gmail.com>:

TL;DR: Don't do it :)

First, note that itemref loops are invalid and will not produce sane
output, so there's no point in deliberately creating such loops.
Still, here is one such example:

<div itemscope>
<div id="a" itemprop="a" itemscope itemref="b"></div>
<div id="b" itemprop="b" itemscope itemref="a"></div>
</div>

(The example you gave isn't a loop, because the md_me doesn't have an
itemprop attribute.)

How to deal with loops created by itemref was changed very recently.
Now, if you create such loops, you'll get a property value "ERROR" in
JSON, see this example:

http://foolip.org/microdatajs/live/?html=%3Cdiv%20itemscope%3E%0A%20%20%3Cdiv%20id%3D%22a%22%20itemprop%3D%22a%22%20itemscope%20itemref%3D%22b%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20id%3D%22b%22%20itemprop%3D%22b%22%20itemscope%20itemref%3D%22a%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E#json

--
Philip Jägenstedt

黃耀賢 (Yau-Hsien Huang)

unread,
Jul 13, 2011, 11:46:24 PM7/13/11
to schemaorg-...@googlegroups.com
On Thursday, July 14, 2011 7:12:01 AM UTC+8, Philip Jägenstedt wrote:

<div itemscope>
  <div id="a" itemprop="a" itemscope itemref="b"></div>
  <div id="b" itemprop="b" itemscope itemref="a"></div>
</div>

(The example you gave isn't a loop, because the md_me doesn't have an
itemprop attribute.)


Nice example. However about what said, "because the md_me doesn't have
an itemprop attribute," right, it does. But it's not the problem. By the draft
http://www.w3.org/TR/microdata/ ) I know an itemscope may have itemref
attribute containing space-separated IDs, but I'd never see any mention
about that any block with itemref-ed ID need be an itemprop.

In my example,

<meta itemprop="about" itemscope itemtype="http://schema.org/Person"
                  itemref="md_me" />

it's an itemscope and then it can have an itemref attribute. It's OK. And it
cannot be just with an itemref without the itemscope. And on referee,

<div id="md_me">
    <div itemprop="name"><strong>Y-H Huang</strong></div>
    <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
        <div>P.O. Box: <span itemprop="postOfficeBoxNumber">241</div>
    </div>
</div>

The tag ID "md_me" has no itemprop. What matters? It includes some
elements representing itemprops. It's OK.

/yhh

Philip Jägenstedt

unread,
Jul 14, 2011, 3:12:11 AM7/14/11
to schemaorg-...@googlegroups.com
2011/7/14 黃耀賢 (Yau-Hsien Huang) <g9414002.p...@gmail.com>:

In your first mail there were two examples. The first is invalid
because it creates an "about" property on "address" which then in turn
has another "address" property. However, I was looking at the second
of your examples, so let's focus on that.

When you use itemref, everything behaves just as if the itemref'd
element were a child element of the itemscope'd element itself. Thus,
these two are equivalent:

<div itemscope itemref="other"></div>
<div id="other" itemprop="fooItem" itemscope>
<div itemprop="fooProp">foo</div>
</div>

<div itemscope>
<div itemprop="fooItem" itemscope>
<div itemprop="fooProp">foo</div>
</div>
</div>

If that much is clear, consider what this means:

<div itemscope>
<div itemscope>
<div itemprop="fooProp">foo</div>
</div>
</div>

Because the inner itemscope'd element does not have an itemprop
attribute, it has no relation to the outer item. They're simply
independent items. This follows from the definition of a top-level:
"An item is a top-level microdata item if its element does not have an
itemprop attribute." [1]

In other words, because <div id="md_me" itemscope
itemtype="http://schema.org/Person"> does not have an itemprop
attribute, it does not become an item of <meta itemprop="about"


itemscope itemtype="http://schema.org/Person" itemref="md_me" />

As you can see, it's quite hard to create an itemref loop that does
anything useful. That all good, because it's invalid and nobody should
do it :)

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#top-level-microdata-items

--
Philip Jägenstedt

黃耀賢 (Yau-Hsien Huang)

unread,
Jul 14, 2011, 8:36:18 AM7/14/11
to schemaorg-...@googlegroups.com
On Thursday, July 14, 2011 3:12:11 PM UTC+8, Philip Jägenstedt wrote:
2011/7/14 黃耀賢 (Yau-Hsien Huang) <g9414002.pccu.edu.tw@gmail.com>:

In your first mail there were two examples. The first is invalid
because it creates an "about" property on "address" which then in turn
has another "address" property. However, I was looking at the second
of your examples, so let's focus on that.

No, it's not error. First, I'd mentioned that the reason why an "about" is
in the "address" is that it's supposed, that is, an assumption, and I said
it's a TEST for microdata rather than schema.org. Secondly, It's not
error because of extension mechanism of shema.org itself.

When you use itemref, everything behaves just as if the itemref'd
element were a child element of the itemscope'd element itself. Thus,
these two are equivalent:

What you said is an example, while others exist. I've used an itemref
referring to a block including many itemprops and itemscopes. It's OK!

<div itemscope itemref="other"></div>
<div id="other" itemprop="fooItem" itemscope>
  <div itemprop="fooProp">foo</div>
</div>

In the example above, you have an itemref to "other,"
and the "other" *must* be *only* itemprop, as you said,
and then it will be hell because when you have more than
one itemprops referred, it need be

      <div itemscope itemref="a b c d e"></div>
      <div id="a" itemprop="..."></div>
      <div id="b" itemprop="..."></div>
      <div id="c" itemprop="..."></div>
      ......

However, the draft never restrict only into this case.
What the hell do you have to do that? No.
It's just

      <div itemscope itemref="others"></div>
      <div id="others">
          <div id="a" itemprop="..."></div>
          <div id="b" itemprop="..."></div>
          <div id="c" itemprop="..."></div>
          ...
      </div>

OK.

<div itemscope>
  <div itemprop="fooItem" itemscope>
    <div itemprop="fooProp">foo</div>
  </div>
</div>

If that much is clear, consider what this means:

<div itemscope>
  <div itemscope>
    <div itemprop="fooProp">foo</div>
  </div>
</div>

Because the inner itemscope'd element does not have an itemprop
attribute, it has no relation to the outer item. They're simply
independent items. This follows from the definition of a top-level:
"An item is a top-level microdata item if its element does not have an
itemprop attribute." [1]

In other words, because <div id="md_me" itemscope
itemtype="http://schema.org/Person"> does not have an itemprop
attribute, it does not become an item of <meta itemprop="about"
itemscope itemtype="http://schema.org/Person" itemref="md_me" />


I've told you that the tag
     <meta itemprop="about" itemscope itemtype="..." itemref=md_me" />
have tagged the itemprop, so the block
     <div id="md_me">
may not be an itemprop. It's a normal HTML structure and it's OK.
The referrer *is* an itemprop, so the referee won't be an itemprop again!

As you can see, it's quite hard to create an itemref loop that does
anything useful. That all good, because it's invalid and nobody should
do it :)

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#top-level-microdata-items

--
Philip Jägenstedt


Yes, I tried the recursive notation. But I did not said "it's OK to write
a recursive metadata." OK?

Stop fool people about the ID itemref-ed must be some itemprop.
The draft or specification never say it. If it's true, microdata will be not
flexible such as a person got spondylitis.

/yhh


黃耀賢 (Yau-Hsien Huang)

unread,
Jul 14, 2011, 8:51:35 AM7/14/11
to schemaorg-...@googlegroups.com
On Thursday, July 14, 2011 3:12:11 PM UTC+8, Philip Jägenstedt wrote:

In other words, because <div id="md_me" itemscope
itemtype="http://schema.org/Person"> does not have an itemprop
attribute, it does not become an item of <meta itemprop="about"
itemscope itemtype="http://schema.org/Person" itemref="md_me" />

...... 
Look at the example blow the context you quoted in [1].
The ID "licenses" itemref-ed is not an itemprop but including
an itemprop embedded in an ahchor.

How did you get the conclusion about above "In other word," blah?
Stop fool people.


Philip Jägenstedt

unread,
Jul 14, 2011, 10:46:52 AM7/14/11
to schemaorg-...@googlegroups.com
2011/7/14 黃耀賢 (Yau-Hsien Huang) <g9414002.p...@gmail.com>:
> On Thursday, July 14, 2011 3:12:11 PM UTC+8, Philip Jägenstedt wrote:
>>
>> 2011/7/14 黃耀賢 (Yau-Hsien Huang) <g9414002.p...@gmail.com>:

>>
>> In your first mail there were two examples. The first is invalid
>>
>> because it creates an "about" property on "address" which then in turn
>> has another "address" property. However, I was looking at the second
>> of your examples, so let's focus on that.
>
> No, it's not error. First, I'd mentioned that the reason why an "about" is
> in the "address" is that it's supposed, that is, an assumption, and I said
> it's a TEST for microdata rather than schema.org. Secondly, It's not
> error because of extension mechanism of shema.org itself.

OK, I was just pointing out that something seems to be wrong, by all
means test away!

(However, http://schema.org/docs/extension.html does not say that you
can add arbitrary properties, only extend them on the form
musicGroupMember/leadVocalist)

Yes, that's also fine. As far as I can tell, everything I've written
so far is correct. I certainly haven't said that *any* element
referred to with itemref must have an itemprop attribute, because that
is incorrect.

Perhaps I have completely misunderstood what you were actually asking.
If by "recursive microdata" you mean itemref loops, the only way that
could happen is if both items in the loop have both itemscope
(obviously) and itemprop (because otherwise they can't be properties
of another item and therefore not be part of a loop).

>> As you can see, it's quite hard to create an itemref loop that does
>> anything useful. That all good, because it's invalid and nobody should
>> do it :)
>>
>> [1]
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#top-level-microdata-items
>>
>

> Yes, I tried the recursive notation. But I did not said "it's OK to write
> a recursive metadata." OK?
>
> Stop fool people about the ID itemref-ed must be some itemprop.
> The draft or specification never say it. If it's true, microdata will be not
> flexible such as a person got spondylitis.

Calm down and please be less rude, I am only doing my best to
understand and answer your questions. No one is actively trying to
fool anyone, at worst there is honest misunderstanding.

--
Philip Jägenstedt

Reply all
Reply to author
Forward
0 new messages