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

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?

cheers,

Dan

Received on Wednesday, 29 February 2012 20:14:07 UTC