Re: working of schema.org/WebPage

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) 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 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), 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 Sunday, 20 April 2014 19:47:28 UTC