- From: Jarno van Driel <jarnovandriel@gmail.com>
- Date: Mon, 4 Aug 2014 14:48:33 +0200
- To: "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>
- Cc: Gregg Kellogg <gregg@greggkellogg.net>, Dan Brickley <danbri@google.com>, "Wallis,Richard" <Richard.Wallis@oclc.org>, W3C Web Schemas Task Force <public-vocabs@w3.org>, "Jason Johnson (BING)" <jasjoh@microsoft.com>, Juraj Kabát <kabat.juraj@gmail.com>, Thad Guidry <thadguidry@gmail.com>
- Message-ID: <CADK2AU1Yq2nna3=Hy_NvSyX_KCF1wdxVuSCPmKn2FxDV-ZTQyA@mail.gmail.com>
> > "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". This I understand. I am just left wondering how the meaning than be inferred if there is no inverseOf value for a property? Or isn't this an issue and is the reverse-relation statement expressive enough? 2014-08-04 13:41 GMT+02:00 martin.hepp@ebusiness-unibw.org < martin.hepp@ebusiness-unibw.org>: > 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 12:49:02 UTC