Re: working of schema.org/WebPage

I always understood that defining the subject of a page is something
different as it's 'main' content. I for example use 'about' as such:

<body itemscope
itemtype="http://schema.org*/CollectionPage*<http://schema.org/CollectionPage>
">
    <div itemprop="about"  itemscope
itemtype="http://schema.org/*Thing*<http://schema.org/Thing>
">
        <span itemprop="name">Appels</span>
    </div>

    <div itemscope itemtype http://schema.org/ImageObject>
        <span itemprop="name">Granny Smith</span>
    </div>

    <div itemscope itemtype http://schema.org/ImageObject>
        <span itemprop="name">Royal Gala</span>
    </div>

    <div itemscope itemtype http://schema.org/ImageObject>
        <span itemprop="name">Pink Lady</span>
    </div>
</body>

though I'd like to able to express:

    <div itemprop="mainContentOfPage" itemscope itemtype
http://schema.org/ImageObject>
        <span itemprop="name">Granny Smith</span>
    </div>


On Mon, Apr 28, 2014 at 9:52 AM, Jocelyn Fournier <
jocelyn.fournier@gmail.com> wrote:

> 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 08:00:53 UTC