Re: Finalizing Reservation schemas for schema.org

Hi elf, all:

I think there are two issues:

Yes, we need a good integration with the GoodRelations part of schema.org, and this could come from http://www.heppnetz.de/ontologies/tio/ns. This will be important so that the proposal is aligned with the core notion of Agent-Offer-OfferedObject, because otherwise we will run into ugly patterns e.g. for bundles of tickets and physical objects etc.

However, I understand that the proposal mainly covers information for actions / transactions, e.g. for use in confirmation emails and HTML documents, so that Google Mail or other clients can process it in PIM applications. Then, the interface is less critical.

If we want to describe offers for tickets, flights, and rental cars, there is huge overlap. 

In general, as soon as offers of something are made, patterns and extensions should be build around http://schema.org/Offer in order to not break the universal e-commerce model of schema.org.

So I think for the moment, the following things will do:

0. Communicate clearly that this is for confirmations / transactions, and that offers should be based on http://schema.org/Offer.

Proposal: Add the following note to Reservation and all subtypes:

"Note: This type is for information about actual reservations, e.g. in confirmation emails or HTML pages with individual confirmations of reservations. For offers of tickets, restaurant reservations, flights, or rental cars, use http://schema.org/Offer."

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.

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.

3. Seat

For Seat.section and Seat.seatingType allow Text OR http://schema.org/QualitativeValue.

4. Thing > Reservation > ReservationPackage

I think this should rather be a subtype of Collection, because a ReservationPackage is not a reservation (arguably).

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.

The properties duration and distance should allow Text OR http://schema.org/Duration .

Sites can then expose more granular data if they have ISO 8601 data.

6. Thing > Reservation > FoodEstablishmentReservation

partySize should allow Number OR http://schema.org/QuantitativeValue, because then you have a pattern for saying "table for 6 - 8 people".

add endTime with a range of dateTime, in case the duration of the stay is limited.

7. Thing > Product > Car > RentalCar

I would drop that type, since the rental car company should be simply the Organization making the Offer, or the provider property of http://schema.org/Reservation.

That is redundant and confusing.

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.

9.  Thing > Reservation >LodgingReservation

lodingUnitType  -> range should be Text OR http://schema.org/QualitativeValue.

numAdults should allow Number OR http://schema.org/QuantitativeValue 
numChildren should allow Number OR http://schema.org/QuantitativeValue  

so that you can express ranges (1-2 adults and 0-2 children).

Note that I chose a different pattern with http://www.heppnetz.de/ontologies/tio/ns#ageRange so that you can define individual age ranges, because I think there are many different types of categorization in use. Maybe you can draw from that.

lodgingUnitDescription - is that any different from the generic description property?

That's it for now.

Martin




 

On Jan 24, 2014, at 10:15 AM, ☮ elf Pavlik ☮ wrote:

> On 01/23/2014 11:33 PM, Vicki Tardif Holland wrote:
>> Instead of having the information within a reservation, the reservation
>> could refer to a TrainTrip (or some other, better term. Forgive me. It's
>> getting late here). The TrainTrip would specify the arrival/departure
>> information.
>> 
>> A train schedule is a list of TrainTrips.
>> 
>> The Flight type (in the same proposal) uses such a pattern. A
>> FlightReservation refers to a Flight.
> how does this work relate to http://www.heppnetz.de/ontologies/tio/ns ?
> 

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

Received on Friday, 24 January 2014 11:02:53 UTC