Re: working of schema.org/WebPage

Le 20/04/2014 22:05, Jarno van Driel a écrit :
>     "It sounds like you have a reasonable argument for that!"
>
>
> Thanks for the support. What is the actual status of the the Periodical
> proposal by the way? Is it a done deal,does it only need votes, or are
> there still open issues?
>
> Because if there still are issues, it would make sense to me to include
> this in the Periodical proposal as well. It seems a waste of time and
> energy to me to expand to CreativeWork first only to be followed by
> expanding it to Thing. We might as well do it in go.
>
> And if that's an option, I'll be more than happy to help. Just let me
> know what I can do.


Hi,

Another issue with schema.org/WebPage : the use of the "about" property.
For me the right way to markup an ItemPage about a product is :

<body itemscope itemtype="http://schema.org/ItemPage">

<div itemprop="about" class="container" itemscope 
itemtype="http://schema.org/Product">
[...]

However, the use of itemprop="about" completely remove the rich snippets 
related to the product. (if I remove itemprop="about", the snippet 
appears again).

e.g. : 
http://www.google.com/webmasters/tools/richsnippets?q=uploaded:8004f8158d05057c17d7e28209fa182d

But perhaps I'm wrong here ?

Thanks,
   Jocelyn Fournier



>
>
> On Sun, Apr 20, 2014 at 9:46 PM, Dan Scott <dan@coffeecode.net
> <mailto:dan@coffeecode.net>> wrote:
>
>     On Sun, Apr 20, 2014 at 08:38:33PM +0200, Jarno van Driel wrote:
>
>         "...might be of interest to you."
>         I've been trying to follow along with that thread as much as I
>         can but I
>         find it difficult due to it's complexity. Now I just read the
>         proposal and
>         it seems actually makes sense to me, so I was wondering, is this
>         the final
>         draft?
>
>         And to pull in something from that proposal: @isPartOf and @hasPart.
>
>         Looking at the current proposal for adding a reverse mechanism
>         to Microdata
>         (https://www.w3.org/wiki/__WebSchemas/InverseProperties
>         <https://www.w3.org/wiki/WebSchemas/InverseProperties>) and
>         imagining it
>         gets accepted, would @hasPart still be needed? RDFa, MIcrodata
>         and JSON-LD
>         all would be able to express the opposite of @isPartOf. Or
>         should it stay
>         part of the proposal simply to make life easier for those who
>         are looking
>         for a property like @hasPart and aren't aware of the existence
>         of a reverse
>         mechanism?
>
>
>     _If_ Microdata adds a reverse mechanism, then inverse properties would
>     not be necessary. We would change the examples to demonstrate the
>     use of the reverse mechanism so that those who aren't aware of the
>     existence of a reverse mechanism would become aware of them in a useful
>     context!
>
>     However, when we created the Periodical proposal in late 2013, the
>     Microdata spec had been relatively static (no significant changes since
>     late 2012, with the exception of the "Converting HTML to JSON" section)
>     and we were under the impression that the schema.org
>     <http://schema.org> partners were only
>     parsing the RDFa Lite portion of the RDFa spec (which wouldn't include
>     @rev). Proposals can only reflect their contexts :)
>
>
>         Now I recall, you and Karen Coyle saying something about using
>         @hasPart for
>         WebPageElements in a previous thread by Martin Hepp (
>         http://lists.w3.org/Archives/__Public/public-vocabs/2014Jan/__0091.html
>         <http://lists.w3.org/Archives/Public/public-vocabs/2014Jan/0091.html>),
>         and
>         like I said in that thread, I am quite ok with using @*Part* for
>         this.
>         Makes perfect sense to me to do it like that.
>
>         But I don't hink having @mainContentOfPage bound to CreativeWork
>         is enough.
>         Many sites describe a Product, Event, MedicalProcedure, etc, all
>         types
>         which aren't part of CreativeWork, yet which are marked up
>         because they are
>         the main entity of that page. After all most sites don't go any
>         further
>         with their markup than that.
>
>
>     Right, we were focused on the needs of the Periodical proposal, where
>     CreativeWork appeared to be the appropriate domain and range for hasPart
>     / isPartOf.
>
>     So perhaps another proposal with different requirements would recommend
>     an even broader range for isPartOf, so that Event and MedicalProcedure
>     could be properly accommodated as well (although part of me wants to
>     make MedicalProcedure, with all of its Text properties, a subclass of
>     CreativeWork...) It sounds like you have a reasonable argument for that!
>
>

Received on Monday, 28 April 2014 07:52:40 UTC