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

On Thu, Mar 1, 2012 at 8:22 AM, Dan Brickley <danbri@danbri.org> wrote:

> On 1 March 2012 02:06, Jason Douglas <jasondouglas@google.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."
> >
> >
> > I think this last one is worth highlighting for broader discussion too.
>  As
> > I understand it, the question is about whether a) Thing/url is the
> identity
> > of the item (equivalent to itemid and conceptually akin to rel=canonical
> for
> > that specific item) or whether b) it's ok for Thing/url to point to any
> URL
> > that represents the same real-world entity, even if it's a different
> > manifestation (e.g., someone else's database record for that entity).
>
> Ah yes, I'd forgotten that nuance. I tend to read Thing/url as approx
> what we had in FOAF isPrimaryTopicOf (but more accessibly named :)
>
> But yes, it seems to have more of the flavour of (a), ie. id for the
> description/record not the thing it describes.
>
> > My understanding has been a) (equivalent to itemid), and that Thing/url
> was
> > provided mostly as a convenience for being able to markup existing anchor
> > tags without having to repeat the URL in the page markup (which itemid
> > requires).
>
> A fine motivation.
>
> > However, accepting the proposed change would effectively eliminate
> option a)
> > and mean that Thing/url was instead meant to express equivalence rather
> than
> > identity.  This would also mean that itemids (rather than Thing/url)
> would
> > have to be declared in order to link schema.org objects (meaning
> specifying
> > objects as values by reference rather than nesting them).
>
> Absorbing this, but yes I think I agree.
>
> > The alternative, as stated in the doc, is to create Thing/sameAs for
> these
> > equivalence use cases.  I personally prefer that option.
>
> In terms of the broader issue, not just Event, it feels like we'd
> benefit from a little 3 or 4 file set of test cases. Maybe describing
> a movie and actor, to show how we want things to connect up, and the
> role sameAs might play. I'm used to the role owl:sameAs plays in the
> RDF and linked data world, but not sure that's quite what you're
> looking for here. Is it a relationship between an entity and another
> description of that same entity?
>

Yes.  So on the Netflix page for a movie, Thing/sameAs could point to the
IMDB page for the same movie.  Or NY Times topic page could point to the
Wikipedia page of the equivalent topic.  Or a site using the Freebase data
could point to the Freebase page for that entity.

-jason


>
> cheers,
>
> Dan
>