Re: Inverse Properties in Microdata:, was Re: schema.org update, v1.8: added WebSite type; broadened isPartOf to relate CreativeWorks

>
> "I think you may be confusing the expressed data model, with the
> semantics of the vocabulary terms"


Yep, I was. Thanks for pointing it out.   :)

"there is no lookup process that turns schema:member into schema:memberOf;
> that can be inferred using semantics"


OK, so if I understand this correct, from a syntax perspective there's
nothing wrong with <div itemprop-reverse="isPartOf" itemprop="isPartOf"...>
but it's meaning depends on schema.org?

If so, how can the meaning than be inferred if there is no inverseOf value
for 'isPartOf'? Or isn't this an issue and is the reverse-relation
statement expressive enough?


> "your example would be simpler for most webmasters to follow"


I think it's a little bit easier to read but on the other hand it requires
the use of identifiers, which often cause the need for additional
programming when building custom HTML templates. A burden many programmers
prefer to avoid and why the use of properties like @id ( + @itemref) or
(@itemid + href) aren't very popular. And when it comes to online
marketers/seo consultants, who advise about the use of schema.org, well
unfortunately - in my experience - many (if not most) don't have the
technical skills to be able to markup as such nor advice about it; as well
as not seeing the value of taking it that far with schema.org.

There's still a lot do in regards to getting the information out there. and
maybe its an idea schema.org also start to incompass examples that make use
of @itemid, @itemref, @rel, @resource, @rev, etc. Because the most heard
complaint I get when talking about it with others is: "where did you get
that info?" or "where can I find more examples?". Now I'm not aware of any
page on any of the sponsors sites which demonstrates anything like this,
nor on schema.org itself. And those are the places where most folks for
information...


> "but the use of @itemprop and @itemprop-reverse on the same element is
> subject to debate."


Like I said, it hadn't occurred to me to do it this way, but personally I
like it, it looks clean and effective. But I don't believe there's a
preferred way to do it from a developer's perspective. Especially when
building (CMS) templates the 'best' way to do it often often depends on
which template file you're working on and to which data you have access to
from within that template. Which often forces one to to deviate from the
'ideal' markup pattern and coming up with creative workarounds and
different solutions.

"in which case a processor seeing the same anonymous @itemscope twice may
> not generate the same BNode."


Makes sense, although I have no experience building parsers, so I can't say
I have an opinion about whether this should be allowed from that
perspective.


2014-08-03 19:42 GMT+02:00 Gregg Kellogg <gregg@greggkellogg.net>:

> On Aug 3, 2014, at 7:56 AM, Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
>
> OK, let me continue to be the student for a moment please.
>
> I understand Gregg's example, but what he wrote I would have written as:
>
> <div itemid="#Organization" itemscope itemtype="
> http://schema.org/Organization">
>     <span itemprop="name">Cryptography Users</span>
>     <div itemid="#OrganizationRole" itemprop="member" itemscope itemtype="
> http://schema.org/OrganizationRole">
>         <link itemprop-reverse="member" href="#Organization">
>         <div itemprop="member" itemscope itemtype="
> http://schema.org/Person">
>             <link itemprop-reverse="member" href="#OrganizationRole">
>             <span itemprop="name">Alice</span>
>         </div>
>         <span itemprop="startDate">1977</span>
>     </div>
> </div>
>
> where I understand:
> itemprop="member" equals 'has member'
> and
> itemprop-reverse="member" equals 'is member of'
>
>
> I think you may be confusing the expressed data model, with the semantics
> of the vocabulary terms. Schema.org defines "memberOf" as the inverseOf
> "member", but this is a semantic definition. A processor does not
> (typically) make use of the semantics, but uses syntax to express the
> model. In both cases, we use the "member" property, so it's the
> schema:member relationship which is defined, there is no lookup process
> that turns schema:member into schema:memberOf; that can be inferred using
> semantics, presuming that schema:inverseOf is similar to owl:inverseOf, :s
> schema:memberOf :o implies :o schema:member :s.
>
> Your example is semantically equivalent to my own, but makes use of
> identifiers for the various objects, rather than anonymous nodes, which is
> just fine. I was attempting to do the minimal change to the Role example
> already existing in the schema.org documentation, but the use of
> @itemprop and @itemprop-reverse on the same element is subject to debate.
> As it happens, in my implementation, it works just fine, but Microdata to
> RDF is defined using DOM functions (specifically, element.properties).
> WHATWG may decide to implement something similar to
> element.reverseProperties, in which case a processor seeing the same
> anonymous @itemscope twice may not generate the same BNode.
>
> I do think it's simpler for authors to not need to worry about such
> interactions, and simply be explicit about the nodes being referred to by
> using @itemid; your example would be simpler for most webmasters to follow,
> which is why I added the "must not" bit on the simultaneous use of
> @itemprop and @itemprop-reverse, but I'm not sure that this is, in fact,
> strictly required.
>
> I just never occurred to me, that if the values 'member' and 'memberOf'
> exist that one could express a reverse relation this way:
> <div itemprop-reverse="memberOf" itemprop="member" itemscope itemtype="
> http://schema.org/OrganizationRole">
>
> Do I understand it right this can only be done in case a property and it's
> opposite exist?
>
>
> This follows from RDFa, where you would write:
>
> <div rev="memberOf" rel="member" typeOf="schema:OrganizationRole">...</div>
>
> As I understand it, @itemprop-reverse is intended to give Microdata the
> same capability, which it seems that it does, although it may be forbidden
> by the HTML5 content model, or may achieve different results depending on
> the definition of the hypothetical element.reverseProperties.
>
> Gregg
>
> 2014-08-03 16:46 GMT+02:00 Gregg Kellogg <gregg@greggkellogg.net>:
>
>> On Aug 3, 2014, at 4:45 AM, Jarno van Driel <jarnovandriel@gmail.com>
>> wrote:
>>
>> mmmmm, could it be there's a misunderstanding on the working of
>> itemprop-reverse (and something that needs to be explained better in the
>> proposal)?
>>
>> The way I understood it is that:
>> itemprop-reverse="memberOf" equals itemprop="member", or,
>> itemprop-reverse="hasPart" equals itemprop="isPartOf".
>>
>> Meaning itemprop-reverse is meant to express the opposite value of a
>> property but not to express a reverse relation.
>>
>>
>> The wording seems pretty clear:
>>
>> [[[
>> The new attribute @itemprop-reverse will be equivalent to the existing
>> @itemprop, except for the fact that the subject and the object of the
>> statement are swapped.
>> ]]]
>> This makes @itemprop-reverse behave just like @rev in RDFa.
>>
>> Gregg
>>
>> Dan Brinkley, Martin Hepp and Thad Guidry, how do you see this?
>>
>>
>> 2014-08-02 23:56 GMT+02:00 Gregg Kellogg <gregg@greggkellogg.net>:
>>
>>> On Aug 1, 2014, at 7:50 AM, Dan Brickley <danbri@google.com> wrote:
>>>
>>> > On 1 August 2014 15:35, martin.hepp@ebusiness-unibw.org
>>> > <martin.hepp@ebusiness-unibw.org> wrote:
>>> >> Richard, Jarno:
>>> >>
>>> >> Note that the itemprop-reverse proposal does not imply that there
>>> should be no inverse properties in schema.org. It is just that we
>>> should be able to use properties in both directions without the need to
>>> define two properties, one for each direction. Inverse properties in the
>>> vocabulary can make sense in some cases (like in the ongoing thread).
>>> >>
>>> >> So we should be clear about the fact that advancing the
>>> itemprop-reverse proposal does not stop you from having both isPartOf and
>>> hasPart. We should define inverses formally in the vocabulary (e.g. by
>>> adding a property http://schema.org/inverseOf to the meta-model of
>>> schema.org).
>>> >
>>> > Indeed. Personally I'm pretty supportive of hasPart, although it is
>>> > hard to know where to draw the line. We didn't do it in the last
>>> > revision when the focus was more on WebSite and we generalized
>>> > isPartOf as a side effect. Both isPartOf and
>>> > http://schema.org/containedIn have the awkward characteristic that the
>>> > point from 'inner' things to 'outer', even while markup structure
>>> > generally starts with containers and has their parts 'inside' in
>>> > markup terms. We're taking a good look at Periodical this week so will
>>> > get back to you all on that asap.
>>> >
>>> > BTW
>>> https://www.w3.org/wiki/WebSchemas/Periodicals,_Articles_and_Multi-volume_Works
>>> > would benefit from "we think this is pretty much done" -style
>>> > read-throughs from other folk here. I've bounced it off a few more
>>> > contacts from the library/bibliographic world and it seems to about
>>> > right....
>>>
>>> I've updated my Microdata to RDF implementation [1] to support
>>> @itemprop-reverse, and need to clarify the interaction with @itemprop.
>>> Consider the following example:
>>>
>>>             <div itemscope itemtype="http://schema.org/Organization">
>>>               <span itemprop="name">Cryptography Users</span>
>>>               <div itemprop-reverse="memberOf" itemprop="member"
>>> itemscope
>>>                     itemtype="http://schema.org/OrganizationRole">
>>>                 <div itemprop-reverse="memberOf" itemprop="member"
>>> itemscope
>>>                         itemtype="http://schema.org/Person">
>>>                   <span itemprop="name">Alice</span>
>>>                 </div>
>>>                 <span itemprop="startDate">1977</span>
>>>               </div>
>>>             </div>
>>>
>>> This doubly-links a Role, using memberOf as the inverse of member. The
>>> resulting Turtle, would be:
>>>
>>>             @prefix schema: <http://schema.org/> .
>>>             @prefix md: <http://www.w3.org/ns/md#> .
>>>             <> md:item (_:a) .
>>>             _:a a schema:Organization;
>>>                 schema:name "Cryptography Users";
>>>                 schema:member _:b .
>>>             _:b a schema:OrganizationRole;
>>>                 schema:startDate "1977";
>>>                 schema:member _:c;
>>>                 schema:memberOf _:a .
>>>             _:c a schema:Person;
>>>                 schema:name "Alice";
>>>                 schema:memberOf _:b .
>>>
>>> However, it's not clear that Microdata would support having both
>>> @itemprop and @itemprop-reverse on the same element. I updated the Wiki to
>>> indicate no, but this needs to be clarified with WHATWG and this list.
>>>
>>> (I'm also considering just dropping the md:item list, as not being too
>>> useful; feedback on this would be appreciated.
>>>
>>> You can use this live through my distiller [2] (although, not the linter
>>> yet).
>>>
>>> Gregg
>>>
>>> [1] https://github.com/ruby-rdf/rdf-microdata
>>> [2] http://rdf.greggkellogg.net/distiller
>>>
>>> > Dan
>>> >
>>> >> Martin
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 01 Aug 2014, at 15:56, Wallis,Richard <Richard.Wallis@oclc.org>
>>> wrote:
>>> >>
>>> >>> Agree that pushing for reverse property capability in Microdata is a
>>> good thing.
>>> >>>
>>> >>> However, I must harmonise with Jarno about hasPart [click, hasPart -
>>> click, hasPart - click..] as proposed in several places including the
>>> Periodicals, Articles, & Mult-Volume Works proposal.
>>> >>>
>>> >>> Describing something like a multi-volume work, for example it is
>>> quite possible that the individual parts are defined elsewhere on the web,
>>> without knowledge of the the multi-volume description
>>> >>>
>>> >>>
>>> >>> ~Richard
>>> >>>
>>> >>>
>>> >>> On 1 Aug 2014, at 09:59, Jarno van Driel <jarnovandriel@gmail.com>
>>> wrote:
>>> >>>
>>> >>>> "as Jarno knows, for he was involved in the discussion ;-)"
>>> >>>> hehe, it could well be I mentioned the existence of the proposal
>>> here and there.
>>> >>>>
>>> >>>> "Anyway, I'll take it to the HTML folks and report back."
>>> >>>> Great, that would help a lot!
>>> >>>>
>>> >>>> Although I have to say (running the risk I sound like a broken
>>> record) that I still believe adding an 'hasPart' property would help a lot
>>> as well. I see both the <link> pointing to an itemid and itemprop-reverse
>>> attribute as more advanced methods for mapping relations and fear that
>>> folks, who are not too familiar with either microdata, will overlook them.
>>> Having 'hasPart' as well will provide an easy and straightforward solution
>>> for a property I suspect will be use quite a lot. Especially if the
>>> schema.org provides sufficient examples on how to use it for layout
>>> entities like WebPage, WebSite, SiteNavigationElement, WebPageElement, etc.
>>> >>>>
>>> >>>>
>>> >>>> 2014-08-01 9:10 GMT+02:00 Dan Brickley <danbri@google.com>:
>>> >>>> On 1 August 2014 07:52, martin.hepp@ebusiness-unibw.org
>>> >>>> <martin.hepp@ebusiness-unibw.org> wrote:
>>> >>>>> There is a fully-fledged proposal to add inverse properties to
>>> microdata:
>>> >>>>>
>>> >>>>>    https://www.w3.org/wiki/WebSchemas/InverseProperties
>>> >>>>>
>>> >>>>> (as Jarno knows, for he was involved in the discussion ;-)
>>> >>>>
>>> >>>> And I well remember too. We had also already begun a discussion on
>>> the
>>> >>>> WHATWG list, so the issue is well established.
>>> >>>>
>>> >>>>> Maybe we can ask Dan to look into this matter again? It would
>>> really help to have this feature.
>>> >>>>
>>> >>>> I think it is indeed time to revisit. I didn't want to push for
>>> >>>> @itemprop-reverse until the Role work stabilised, but now that is
>>> done
>>> >>>> I believe it's time. That said, there is still sometimes
>>> justification
>>> >>>> for adding a reverse property, and the site software now supports
>>> >>>> linking such pairs where they exist (e.g. see
>>> >>>> http://schema.org/alumni). Anyway, I'll take it to the HTML folks
>>> and
>>> >>>> report back.
>>> >>>>
>>> >>>> Dan
>>> >>>>
>>> >>>>> Best wishes / Mit freundlichen Grüßen
>>> >>>>>
>>> >>>>> Martin Hepp
>>> >>>>>
>>> >>>>>
>>> >>>>> On 01 Aug 2014, at 00:40, Jarno van Driel <jarnovandriel@gmail.com>
>>> wrote:
>>> >>>>>
>>> >>>>>> "I notice you don’t have an itemprop attribute in your first
>>> <div> element.  Was that intentional?"
>>> >>>>>>
>>> >>>>>> That would only have been possible if 'hasPart' (which isn't part
>>> of the specification) could have been used (or itemprop-reverse="isPartOf").
>>> >>>>>>
>>> >>>>>> Because there is no inverse property of 'isPartOf', nor a reverse
>>> mechanism for microdata, Juraj is bound to chain the entities together by
>>> making use of <link itemprop="isPartOf" href="[itemid-value]">.
>>> >>>>>>
>>> >>>>>> A cumbersome method, that now can be applied where it first
>>> couldn't. All be it but one that can be improved still.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> 2014-07-31 17:52 GMT+02:00 Jason Johnson (BING) <
>>> jasjoh@microsoft.com>:
>>> >>>>>> I notice you don’t have an itemprop attribute in your first <div>
>>> element.  Was that intentional?
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> From: Juraj Kabát [mailto:kabat.juraj@gmail.com]
>>> >>>>>> Sent: Tuesday, July 29, 2014 8:08 AM
>>> >>>>>> To: public-vocabs@w3.org
>>> >>>>>> Cc: W3C Web Schemas Task Force
>>> >>>>>> Subject: Re: schema.org update, v1.8: added WebSite type;
>>> broadened isPartOf to relate CreativeWorks
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> When Ill try to add isPartOf property to ItemList, Im getting
>>> this warning:
>>> >>>>>>
>>> >>>>>> WARNING: isPartOf field not specified in
>>> http://schema.org/ItemList
>>> >>>>>>
>>> >>>>>> Example snippet:
>>> >>>>>> <body itemid="#WebPage" itemscope itemtype="
>>> http://schema.org/CollectionPage">
>>> >>>>>>    <div class="products" itemscope itemtype="
>>> http://schema.org/ItemList">
>>> >>>>>>        <meta content="Unordered" itemprop="itemListOrder">
>>> >>>>>>        <link itemprop="isPartOf" href="#WebPage">
>>> >>>>>>
>>> >>>>>>        <div itemtype="http://schema.org/Product" itemscope
>>> itemprop="itemListElement">
>>> >>>>>>        <img src="[url]" itemprop="image">
>>> >>>>>>        <a href="[url]" itemprop="url"><span
>>> itemprop="name">[name]</span></a>
>>> >>>>>>      <span itemtype="http://schema.org/Offer" itemscope
>>> itemprop="offers">
>>> >>>>>>            <span itemprop="price">[price]</span>
>>> >>>>>>      </span>
>>> >>>>>>        </div>
>>> >>>>>>
>>> >>>>>>        <div itemtype="http://schema.org/Product" itemscope
>>> itemprop="itemListElement">
>>> >>>>>>        <img src="[url]" itemprop="image">
>>> >>>>>>        <a href="[url]" itemprop="url"><span
>>> itemprop="name">[name]</span></a>
>>> >>>>>>      <span itemtype="http://schema.org/Offer" itemscope
>>> itemprop="offers">
>>> >>>>>>            <span itemprop="price">[price]</span>
>>> >>>>>>      </span>
>>> >>>>>>        </div>
>>> >>>>>>
>>> >>>>>>    </div>
>>> >>>>>> </body>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> But when Ill add isPartOf property to each ItemListElement,
>>> everything works like expected.
>>> >>>>>> What am I missing here? ItemList extends CreativeWork as well...
>>> >>>>>>
>>> >>>>>> Why can't I chain whole ItemList to parent but instead of that I
>>> have to repeat myself for every element in list?
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Mon, Jul 28, 2014 at 10:20 PM, Jarno van Driel <
>>> jarnovandriel@gmail.com> wrote:
>>> >>>>>>
>>> >>>>>> Personally I most of all like the addition of WebSite (and it's
>>> creative example) as well as the reworked 'isPartOf' most and I've already
>>> started to implementing them.  :-)
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> But I would have been an even happier camper if 'hasPart' would
>>> have been introduced as well. And even though chaining WebSite > WebPage >
>>> WebPageElements > CreativeWork now can be achieved, without abusing
>>> 'mentions' for this, it unfortunately is quite cumbersome in microdata
>>> because one has to use itemid quite a lot, eg:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> <body itemid="#WebPage" itemscope itemtype="
>>> http://schema.org/WebPage">
>>> >>>>>>
>>> >>>>>> <nav itemid="#SiteNavigationElement" itemscope itemtype="
>>> http://schema.org/SiteNavigationElement">
>>> >>>>>>
>>> >>>>>> <link itemprop="isPartOf" href="#WebPage">
>>> >>>>>>
>>> >>>>>> <ul>
>>> >>>>>>
>>> >>>>>> <li itemscope itemtype="http://schema.org/WebPage"
>>> itemid="#WebPage-1">
>>> >>>>>>
>>> >>>>>> <link itemprop="isPartOf" href="#SiteNavigationElement">
>>> >>>>>>
>>> >>>>>> <a itemprop="url" href="[some-page-url]">
>>> >>>>>>
>>> >>>>>> <span itemprop="name">[some-page-name]</span>
>>> >>>>>>
>>> >>>>>> </a>
>>> >>>>>>
>>> >>>>>> <ul>
>>> >>>>>>
>>> >>>>>> <li itemscope itemtype="http://schema.org/WebPage">
>>> >>>>>>
>>> >>>>>> <link itemprop="isPartOf" href="#WebPage-1" />
>>> >>>>>>
>>> >>>>>> <a itemprop="url" href="[some-page-url]">
>>> >>>>>>
>>> >>>>>> <span itemprop="name">[some-page-name]</span>
>>> >>>>>>
>>> >>>>>> </a>
>>> >>>>>>
>>> >>>>>> </li>
>>> >>>>>>
>>> >>>>>> <li itemscope itemtype="http://schema.org/WebPage">
>>> >>>>>>
>>> >>>>>> <link itemprop="isPartOf" href="#WebPage-1" />
>>> >>>>>>
>>> >>>>>> <a itemprop="url" href="[some-page-url]">
>>> >>>>>>
>>> >>>>>> <span itemprop="name">[some-page-name]</span>
>>> >>>>>>
>>> >>>>>> </a>
>>> >>>>>>
>>> >>>>>> </li>
>>> >>>>>>
>>> >>>>>> </ul>
>>> >>>>>>
>>> >>>>>> </li>
>>> >>>>>>
>>> >>>>>> </ul>
>>> >>>>>>
>>> >>>>>> </nav>
>>> >>>>>>
>>> >>>>>> </body>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> I'm still quite pleased with the update is as though.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> 2014-07-28 17:43 GMT+02:00 Dan Brickley <danbri@google.com>:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> previous update (1.7),
>>> >>>>>>
>>> http://lists.w3.org/Archives/Public/public-vocabs/2014Jul/0012.html
>>> >>>>>>
>>> >>>>>> A small schema.org update just went live:
>>> >>>>>>
>>> >>>>>> 1. We add a new CreativeWork type, "WebSite"
>>> >>>>>>
>>> >>>>>> http://schema.org/WebSite
>>> >>>>>>
>>> >>>>>> "A WebSite is a set of related web pages and other items typically
>>> >>>>>> served from a single web domain and accessible via URLs."
>>> >>>>>>
>>> >>>>>> The example shows the use of this with SearchAction.
>>> >>>>>>
>>> >>>>>> 2. We adopt the proposal made by the bibextend group and other
>>> >>>>>> collaborators, to broaden isPartOf. It now relates any
>>> CreativeWork to
>>> >>>>>> any other CreativeWork
>>> >>>>>>
>>> >>>>>> http://schema.org/isPartOf
>>> >>>>>>
>>> >>>>>> see also
>>> https://www.w3.org/wiki/WebSchemas/Periodicals,_Articles_and_Multi-volume_Works
>>> >>>>>>
>>> >>>>>> 3. Potential Actions documentation
>>> >>>>>>
>>> >>>>>> The previously PDF-only Potential Actions document is now on the
>>> site in HTML:
>>> >>>>>>
>>> >>>>>> http://schema.org/docs/actions.html
>>> >>>>>>
>>> >>>>>> 4. Adopted some markup fixes from Stephane Corlosquet (thanks!)
>>> >>>>>>
>>> >>>>>> https://github.com/rvguha/schemaorg/pull/71
>>> >>>>>>
>>> >>>>>> 5. Improved consistency of encoding / associatedMedia description
>>> >>>>>> (thanks Dan Scott!)
>>> >>>>>>
>>> >>>>>> https://github.com/rvguha/schemaorg/pull/35
>>> >>>>>>
>>> >>>>>> 6. Updated some out-of-date sections of the FAQ: it now mentions
>>> >>>>>> Yandex appropriately, acknowledges that there's life beyond
>>> Microdata
>>> >>>>>> (i.e. RDFa, JSON-LD), and doesn't talk about "version 0.9 draft"
>>> any
>>> >>>>>> more.
>>> >>>>>>
>>> >>>>>> https://github.com/rvguha/schemaorg/pull/69
>>> >>>>>>
>>> >>>>>> Thanks all :)
>>> >>>>>>
>>> >>>>>> Dan
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>>
>
>

Received on Sunday, 3 August 2014 20:37:39 UTC