Re: Finalizing Reservation schemas for schema.org

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 08:35:23 UTC