- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Thu, 29 May 2014 20:06:55 +0200
- To: "<public-vocabs@w3.org>" <public-vocabs@w3.org>
Trying to clean little corners where dust collects: We currently have http://schema.org/seller http://schema.org/vendor http://schema.org/merchant http://schema.org/provider http://xkcd.com/927 all of which point to the entity who agrees, or may agree, to give something to or do something for you. (Roughly. It could be to someone else…, or for some third party, or…) Working backwards from "provider", which can describe e.g. the issuer of a airplane ticket, we were concerned that it is easy to confuse it with the use of "serviceOperator" - the entity that does the actual work involved in the deal, such as the airline who flies the plane in the ticket example. (Actually In "Flight" this is currently called "carrier", but we propose to change that and align it with "GovernmentService"). It seems to make more sense to use something like "offeredBy" - although we cannot make ambiguity impossible, this seems to reduce the risk to a better level. Having got to that point, it seemed to make sense to supersede all four of the above properties with offeredBy. It isn't clear that there is enough difference between them to justify keeping 4 different terms. Before storming into the schema.org site and imposing such a decision, are there reasons why this is a bad idea, and we should retain the current setup? Or do people think we should have done this last week already? Could we use a chain of "offeredBy" relationships instead of having a bookingAgent for a reservation? E.g. My flight serviceProvider is Lufthansa, the Flight is offeredBy ANA who sold the ticket, but the ticket itself was offeredBy CheapFlightsLimited to me as a consumer… cheers Chaals -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Received on Thursday, 29 May 2014 18:07:35 UTC