Re: working of schema.org/WebPage

>
> "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.


On Sun, Apr 20, 2014 at 9:46 PM, Dan Scott <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) 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!
>