Re: Finalizing Reservation schemas for schema.org

On 28 January 2014 15:31, Vicki Tardif Holland <vtardif@google.com> wrote:
> I sent Dan Brickley a new version of the proposal, which he will post
> shortly.

Ok, I've regenerated the test site, so these are available at urls
like http://sdo-wip2.appspot.com/BusTrip
http://sdo-wip2.appspot.com/Reservation etc

The updated draft schema is in the W3C webschemas mercurial
repository, https://dvcs.w3.org/hg/webschema/log/default/schema.org/ext/Reservation.html

You can see a textual diff of the changes here:
https://dvcs.w3.org/hg/webschema/diff/0c2f7638bcd9/schema.org/ext/Reservation.html

We're getting closer...

cheers,

Dan

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

Received on Tuesday, 28 January 2014 15:38:25 UTC