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

Jarno:
The essential idea of itemprop-reverse is that subject and object of a statement are swapped. This will make markup much simpler if the subject of a statement is either nested inthe HTML DOM inside the object, or if it is an external resource.

The same can be achieved by defining inverse variants for such properties (hasMeber / isMemberOf; hasPart/isPartOf; etc.). While this can be useful for a small set of properties, it is better to support this directly at the level of the markup syntax so that we do not have to define inverse variants for ALL properties, which would blow up the vocabulary.

Best wishes / Mit freundlichen Grüßen

Martin



On 03 Aug 2014, at 22:37, Jarno van Driel <jarnovandriel@gmail.com> wrote:

> "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 Monday, 4 August 2014 11:42:07 UTC