W3C home > Mailing lists > Public > public-vocabs@w3.org > January 2014

Re: Finalizing Reservation schemas for schema.org

From: Vicki Tardif Holland <vtardif@google.com>
Date: Fri, 24 Jan 2014 10:36:56 -0500
Message-ID: <CAOr1obFL=DKFYo_oOBJ8qohmOvCPQpYEEOL6=sHhwDaT=CNMLQ@mail.gmail.com>
To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Cc: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>, PublicVocabs <public-vocabs@w3.org>
To clarify, the intention of this schema is for actions/transactions as
Martin suggested. An offer to sell a ticket should use schema.org/Offer. I
can update the comments to reflect this.

Martin named a number of places where the range should be extended to use
http://schema.org/QualitativeValue or
http://schema.org/QuantitativeValueas appropriate. Those seem like
good suggestions, so unless someone has
strong objections, I will update the draft to reflect those changes.

My other comments are inline.

> 1. for Thing > Ticket
> a) Define two subtypes
> - Actual Ticket or Individual Ticket ( equivalent to
> http://www.heppnetz.de/ontologies/tio/ns#ActualTicket)
> - Some Tickets of Ticket Placeholder or Abstract Ticket or Ticket Templae
> (equivalent to http://www.heppnetz.de/ontologies/tio/ns#TicketPlaceholder)
> b) check that the properties from tio:accessTo tio:scope tio:ticketID
> tio:validFrom tio:validThrough
> http://www.heppnetz.de/ontologies/tio/ns#Ticket
> http://www.heppnetz.de/ontologies/tio/ns#ActualTicket
> http://www.heppnetz.de/ontologies/tio/ns#TicketPlaceholder
> have equivalences.
> Note that Ticket in TIO terms (and GoodRelations terms) is "a tradeable
> right to access a particular event or location, or to use a particular
> transportation service."
> It is not the document but the right that the document entitles to.
> We will need that distinction later on when we want to describe offers for
> tickets.
> If you cannot agree upon that now, renaming the current proposal to
> ActualTicket would also do in order to avoid later confusion with Tickets
> being offered.

<vth> Martin, I am not sure I completely understand this point. Without a
ticketToken (or some other way to validate the ticket), the ticket is in
effect a TicketHolder. Are you concerned that people will get confused
about the semantics of using Ticket?

> 2. Price information
> If price and priceCurreny are only used to indicated what was charged for
> the ticket (in the sense of a payment transaction), it can stay as it is.
> But if the intended use is also to indicate offers to tickets, the new
> http://schema.org/priceSpecification property should be used.
> This done properly will allow for very powerful use-cases like
> "An offer for a family ticket for the Bryan Adams concert at the Verizon
> Wireless Amphitheatre for 1-2 adults and 0-2 kids aged 0-6 years"
> with very little additional elements. See
> http://www.heppnetz.de/ontologies/tio/ns#family_example.
> Conclusion: If the properties are only used for transactions, it can stay
> as it is.
<vth> The intention is to record what the person paid for the ticket in
'price'. I assume an offer price would be part of a http://schema.org/Offer.
Perhaps the price property should be changed to 'pricePaid' or similar to
clarify the difference.

> 5. Thing > Flight
> The property aircraft should allow Text OR http://schema.org/Thing so
> that you can use Freebase or DBPedia URIs or define them in a site.
http://schema.org/Thing seems very broad. Would it be better to have an
aircraft type?

> 8.  Thing > Product > Car
> change that to
>  Thing > Product > Vehicle > Car
> I will propose more types for vehicles shortly, we should already now
> introduce a common abstraction.
<vth> Thank you for mentioning this. I knew there was some automotive stuff
brewing, but was not sure of the state of it.</vth>

- Vicki

Vicki Tardif Holland | Ontologist | vtardif@google.com
Received on Friday, 24 January 2014 15:37:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:21 UTC