Re: Finalizing Reservation schemas for schema.org

I sent Dan Brickley a new version of the proposal, which he will post
shortly. The changes are:

- Created BusTrip to model details of a bus trip. The properties previously
existed on BusReservation.
- Created TrainTrip to model details of a bus trip. The properties
previously existed on TrainReservation.
- Added note to Reservation specifying that http://schema.org/Order should
be used for orders.
- Added  http://schema.org/QualitativeValue as a possible expected type for
Seat > seatType.
- Allowed Text as expected type for Flight > flightDuration.
- Allowed Text as expected type for Flight > flightDistance.
- Allowed http://schema.org/QuantitativeValue as an expected type for
FoodEstablishmentReservation > partySize.
- Added FoodEstablishmentReservation > departTime.
- Changed Thing > Product > Car to Thing > Product > Vehicle > Car.
- Added QualitativeValue as an expected type for LodgingReservation >
lodgingUnitType
- Added QuantitativeValue as an expected type for LodgingReservation >
numAdults.
- Added QuantitativeValue as an expected type for LodgingReservation >
numChildren.


Martin, I just saw your latest round of comments. I will address those
separately.

- Vicki


Vicki Tardif Holland | Ontologist | vtardif@google.com



On Tue, Jan 28, 2014 at 3:34 AM, Martin Hepp <
martin.hepp@ebusiness-unibw.org> wrote:

> Dear Vicki:
> See comments inline:
> On Jan 24, 2014, at 4:36 PM, Vicki Tardif Holland wrote:
>
> > 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/QuantitativeValue as 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>
> >
> >
>
> The main issue is that I would like to preserve the keyword Ticket for a
> future extension for offering tickets.
>
> In the GoodRelations model, a ticket is an actual ticket even without a
> ticketToken, because what matters for the distinction is the ontological
> identity of the entity.
> A TicketPlaceholder is a bag of multiple similar tickets; this is
> historically a pragmatic trick for existential quantification in
> GoodRelations so that you can say "I sell some tickets for the Madonna
> concert on July 4, 2014" as compared to "I sell my ticket for the Madonna
> concert on July 4, 2014".
>
> When people offer new products, they often do not expose the identity of
> the actual products (e.g. Amazon does not have URIs for each book copy they
> sell), whereas in eBay e.g., the item offered is exposed. If you buy a bike
> on Amazon, and I buy the same bike a minute later, we do not own the same
> bike. If I buy a used item on eBay and someone else makes a statement about
> that bike, we are referring to the same object.
>
> But to keep it simple. Just use a different keyword for the particular
> ticket - IssuedTicket, TicketParticular, TicketDetails, TicketConfirmation,
> ...
>
> >
> > 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>
>
> Yes, pricePaid would be perfectly fine, and then maybe change the range
> from Number to Number OR PriceSpecification, so people could use the more
> advanced modeling of that type (see also the ongoing discussion on tax
> information; we would then not need to duplicate efforts for modeling tax
> information).
>
> >
> >
> >
> > 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?
>
> Well, maybe use http://schema.org/Vehicle as proposed elsewhere. But let
> us not be to restrictive here; people could see tickets to fly on a canon
> ball, balloon, jet pack, parachute, rocket to the moon (one day - keep in
> mind commercial space trips).
>
> I think Vehicle is broad enough for most cases.
>
> >
> >
> > 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
> >
>
> --------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  hepp@ebusiness-unibw.org
> phone:   +49-(0)89-6004-4217
> fax:     +49-(0)89-6004-4620
> www:     http://www.unibw.de/ebusiness/ (group)
>          http://www.heppnetz.de/ (personal)
> skype:   mfhepp
> twitter: mfhepp
>
> Check out GoodRelations for E-Commerce on the Web of Linked Data!
> =================================================================
> * Project Main Page: http://purl.org/goodrelations/
>
>
>
>