Update (2016)
The use of multi-type entities seems to catch up in Microdata, so using properties not defined for all of the specified types (as described in my old answer below) might be fine in Schema.org.
Anyway, the support for identifiers (in Microdata: with itemid
) seems to be better now (at least it’s supported in Google’s testing tool), and this might be an appropriate solution for your case:
- give the person a URI in
itemid
- reference this URI as value for
author
and formember
Example:
<div itemscope itemtype="http://schema.org/Person" itemid="/team/alice#i">
</div>
<div itemscope itemtype="http://schema.org/LegalService">
<link itemprop="member" href="/team/alice#i" />
</div>
<div itemscope itemtype="http://schema.org/Book">
<link itemprop="author" href="/team/alice#i" />
</div>
Note that the Attorney
type is deprecated now, so I used LegalService
in this example.
Old answer (2014)
(Note that your use of itemref
is not correct, because it can only be used on elements with itemscope
.)
This is not possible with Microdata.
It would lead to the use of properties that are not valid for their parent (whether via nesting or via itemref
) itemtype:
You can’t reference the Person via itemref
for both, the Attorney and the Book, because that would require to use itemprop="author member"
(which is valid syntax-wise) on Person, but author
is not a valid property for Attorney and member
is not a valid property for Book.
Same problem if you‘d nest Person under Book and use itemref
to reference this same Person from Attorney. Or vice-versa.
So the only way I can see is duplicating the information, which is a pity.