- From: Bo Ferri <zazi@smiy.org>
- Date: Fri, 24 May 2013 23:23:01 +0200
- To: public-vocabs@w3.org
Hello again ;) On 5/24/2013 4:59 AM, Yaar Schnitman wrote: > Hi Leigh, Bo, > > Thanks for your input. > > I think that the Actions schema would play well with the Counter > Ontology. Thanks for pointing it out. > > The Actions in Schema.org does not include generalized "target", > "object" and "product" properties, nor "factors", and instead each > action type has its specific properties. One of the motivations behind > this is that schema.org <http://schema.org> markup is done by millions > of webmasters, each usually only needing to know about a very small > number of nouns and verbs. If schema.org <http://schema.org> uses very > generic properties, many webmasters will err, putting wrong values in > the wrong properties. > Well, I don't think that we should always propagate that they should utilised the generic properties. However, that the vocabulary should be designed in this way, that a information systems that consumes these descriptions should be able to infer the generic properties via more specific properties, i.e., that there is a inheritance hierarchy analogous to the type inheritance hierarchy*. > For example, the DriveAction type will have the following properties: > > * vehicle (Vehicle) > * passengers (Person) > * cargo (Thing) > * origin (Place) > * destination (Place) > * averageSpeed (Number) > * mpg (Number) > * route (Route) > * ... > > I think that the schema.org <http://schema.org> specifications could > also denote which properties are the ontological "target" (destination), > "object" (vehicle), "factors" (cargo, passengers, averageSpeed, origin, > ...) and a potential "product" (non in this case). This extra layer of > specification might help bridge the gap between what webmasters would > like to work with and what aggregators & data-crunchers would like to > work with. > exactly. I think that's why Leigh suggested the Event Ontology ;) > Leigh, to answer your specific note about Thing > Action > BuyAction > > BuyTicketAction > BuyMovieTicketAction: > This can be seen as "utility schemas" or "model sugaring". One can > easily describe buying a movie ticket like this with basic pre-existing > schemas: > > { > @type: http://schema.org/BuyAction > actor: "Yaar Schnitman" > itemBought: { > @type: http://schema.org/Ticket > price: $10 > seat: 16 > row: 9 > ticketFor: { > @type: http://schema.org/MovieShowing > movie: { > @type: http://schema.org/Movie > name: "The Hobbit" > } > startTime: 8:30pm > ... > } > } > } > > Semantically correct, but possible too complicated for large scale > adoption by webmasters. The Actions in Schema.org proposal therefore > suggests that for complex use cases that hit adoption problems, > schema.org <http://schema.org> will introduce a specialized BuyAction > > BuyTicketAction > BuyMovieTicketAction, which will allow simpler, > shorter declarations like the following: > > { > @type: http://schema.org/BuyMovieTicketAction > actor: "Yaar Schnitman" > price: $10 > seat: 16 > row: 9 > movie: "The Hobbit" > startTime: 8:30pm > } > > Does this clarify things? Yep, however, where will you start and where will end to provide simplified descriptions for specific use cases. It's hard to find a good balance ... Cheers, Bo *) maybe this contradicts a bit what I wrote before (in my previous response), however, one should balance the level of inheritance to both parts that build the foundation of nearly every knowledge representation approach, i.e., to types as well as to relationships. This is the case when utilising, e.g., RDF and RDFS (at least), or adapting this design directly to schema.org (as it is already proposed).
Received on Friday, 24 May 2013 21:23:40 UTC