Re: Finalizing Reservation schemas for schema.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?
</vth>




> 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.
</vth>



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