Re: Last Call for Comments ... Re: proposal for updates to http://schema.org/Event

On Wed, Feb 29, 2012 at 12:19 PM, Will Norris <will@willnorris.com> wrote:

> On Wed, Feb 29, 2012 at 12:13 PM, Dan Brickley <danbri@danbri.org> wrote:
>
>> On 29 February 2012 21:07, Will Norris <will@willnorris.com> wrote:
>> > On Wed, Feb 29, 2012 at 11:50 AM, Dan Brickley <danbri@danbri.org>
>> wrote:
>> >>
>> >> On 24 February 2012 16:39, Dan Brickley <danbri@danbri.org> wrote:
>> >> > I've just posted another draft proposal in the W3C wiki,
>> >> > http://www.w3.org/wiki/EventSchemaUpdate
>> >> >
>> >> > From the wrapper text there,
>> >> >
>> >> > "The proposal comes from the Google teams working with the existing
>> >> > Event markup, and has been checked by the other schema.org partners
>> >> > prior to publication. See PDF for full details of the proposal."
>> >> >
>> >> > * "Proposes 3 new properties of Event: eventStatus,
>> previousStartDate,
>> >> > previousEndDate to support canceled or rescheduled events.
>> >> > * Adds eventCategory to support categorised events.
>> >> > * Supports recurring events by making startDate and endDate repeated.
>> >> > * Encourages use of existing 'url' property (of Thing) to link to
>> >> > associated Web pages."
>> >> >
>> >> > Feedback as ever welcomed here or in the Wiki.
>> >>
>> >> OK, we didn't get a lot of discussion on this proposal. It has had
>> >> some review elsewhere and is based on implementation feedback on the
>> >> earlier deployed vocab so I suggest we wrap this one up quickly.
>> >>
>> >> Consider this a last call for comments on
>> >> http://www.w3.org/wiki/EventSchemaUpdate, where btw the phrase 'Last
>> >> Call' doesn't have the formality associated with official W3C
>> >> standards. Rather it means, "hey, we're expecting to update schema.org
>> >> based on this draft Real Soon Now and welcome your comments". Thanks
>> >> for any feedback :)
>> >
>> >
>> > my only concern with the proposal is the method proposed for matching
>> > multiple startDate values to their corresponding endDate.  While the
>> > schema.org vocabulary is first and foremost designed for
>> representation as
>> > microdata, that is by no means the only possible representation.  It's
>> not
>> > clear to me how much that should be a factor in defining the vocabulary.
>> >  For example, when doing the JSON transformation as specified in the
>> > microdata spec, you'd end up with:
>> >
>> > {
>> >   "type": "http://schema.org/Event"
>> >   "properties": {
>> >     "startDate": [ "2012-2-3", "2012-2-10", "2012-2-17" ],
>> >     "endDate": [ "2012-2-5", "2012-2-12", "2012-2-19" ],
>> >   }
>> > }
>> >
>> > JSON arrays are not necessarily ordered by definition, and different
>> JSON
>> > parsers behave differently in terms of maintaining order.  Even XML
>> parsers
>> > for that matter do not always maintain order.  Depending on what schema
>> > language you use, I don't believe XML is necessarily ordered.  Does the
>> > microdata spec provide any guidance in terms of element order, and
>> whether
>> > than can or should be relied upon to imply meaning to values?
>>
>> Yes - I kept my concerns quiet on this to see who else was reading,
>> but I share exactly your worry here. Schema.org is deployed initially
>> in Microdata, but the vocabulary is syntax-neutral and other
>> representations (e.g.
>> blog.schema.org/2011/11/using-rdfa-11-lite-with-schemaorg.html ) are
>> important to us. Any thoughts on a structure that would make things
>> more explicit and portable?
>>
>
> Nested event items, along the lines of subEvents?  Named 'repeatedEvents'
> or something similar?
>

+1.  I'm not sure of the exact best pattern either, but I do think nesting
would be a much more reliable pattern than repeated values for all the
reasons mentioned.

-jason