Re: Person job proposal (was Re: Schema.org proposal: Financial information)

Thanks again for the extensive response, and especially in regards to
Product(OrService).

But to be honest I still don't understand when Service should be used.
GovernmentService seems obvious enough but schema.org has 2 types that can
be used to describe a service without clarifying when one should use one or
the other.

Could this maybe be clarified further, and not only as a response because I
ask but also on schema.org itself?

2014-09-20 11:41 GMT+02:00 ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>:

> i captured it in https://github.com/rvguha/schemaorg/issues/134
>
> IMO it got bit buried in this *Re: Person job proposal (was Re:
> Schema.org proposal: Financial information)* thread :(
>
> On 09/20/2014 09:38 AM, martin.hepp@ebusiness-unibw.org wrote:
> > On 19 Sep 2014, at 22:40, Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
> >
> >> Thanks Martin and Thad.
> >>
> >> So... The rest of you looks at Product as if it is ProductOrService.
> >>
> >> In that case (see it coming?): How does the rest of you look at Service?
> >>
> >
> > I suppose that "Service" was once added for some specific, but maybe
> only hypothetical use-case by one of the sponsors of schema.org.
> >
> > In order to keep the vocabulary clean, however, I suggest to use Product
> (in the sense of ProductOrService) as long as the distinction between
> product and service does not really matter for processing the data. Many
> "products" are nowadays bundles of tangible objects and services anyway, so
> unless you need specific properties that do not make sense for
> schema:Product, I would minimize the use of schema:Service.
> >
> > Note: In principle, we could make Service a subclass of Product, and/or
> include a superclass ProductOrService (which was the original name in
> GoodRelations anyway):
> >
> > schema:ProductOrService
> >       -> schema:Product
> >               -> schema:SomeProducts
> >               -> schema:IndividualProduct
> >               -> schema:ProductModel
> >       -> schema:Service
> >
> > This has two caveats, though: First, the more special types
> SomeProducts, IndividualProduct, and ProductModel are then not available
> for services any longer. But on the contrary, the notion of individuals,
> models, and bags of products does not really fit to pure services anyway
> (or they do not matter that much). So this seems acceptable to me.
> >
> > Second, if we want to add specializations for very important types of
> products and services (like Vehicle/Car; HotelRoom, etc.), we will have to
> make a strict decision on whether that type is a product or a service. That
> can lead to inconsistency in the vocabulary over time. For instance, I
> think that "Taxi" should be better placed beneath schema:Product etc. For
> me, this is the reason for rather sticking to the "ProductOrService" notion
> of schema:Product.
> >
> > Also note that you can always indicate that a schema:Product is a
> service via the businessFunction property of the offer:
> >
> > <div itemscope itemtype="http://schema.org/Offer">
> >       <div itemprop="itemOffered" itemscope itemtype="
> http://schema.org/Product">
> >               <div itemprop="name">Manicure</div>
> >               <div itemprop="description">Cosmetic beauty treatment for
> the fingernails and hands</div>
> >       </div>
> >       <link itemprop="businessFunction" href="
> http://purl.org/goodrelations/v1#ProvideService" />
> >       <div itemprop="priceSpecification" itemscope itemtype="
> http://schema.org/UnitPriceSpecification">
> >               <div itemprop="price">45.99</div>
> >               <meta itemprop="priceCurrency" content="USD">$
> >       </div>
> > </div>
> >
> > This is IMO sufficient for modeling most types of services.
> >
> > As a side note: The GoodRelations model in schema.org allows two
> patterns for modeling specific services on products, namely
> construction/installation, disposal, maintenance, and repair via
> >
> >     http://purl.org/goodrelations/v1#ConstructionInstallation
> >     http://purl.org/goodrelations/v1#Dispose
> >     http://purl.org/goodrelations/v1#Maintain
> >     http://purl.org/goodrelations/v1#Repair
> >
> > So a nuclear waste disposal service could either say that the product to
> which the offer refers is "nuclear waste", and the business function is
> "disposal":
> >
> > <div itemscope itemtype="http://schema.org/Offer">
> >       <div itemprop="name">Nuclear Waste Disposal Service</div>
> >       <div itemprop="description">Nuclear Waste Disposal Service</div>
> >       <div itemprop="itemOffered" itemscope itemtype="
> http://schema.org/SomeProducts">
> >               <div itemprop="name">Nuclear Waste</div>
> >       </div>
> >       <link itemprop="businessFunction" href="
> http://purl.org/goodrelations/v1#Dispose" />
> >       <div itemprop="priceSpecification" itemscope itemtype="
> http://schema.org/UnitPriceSpecification">
> >               <div itemprop="price">1000</div>
> >               <meta itemprop="priceCurrency" content="USD">$
> >               <meta itemprop="unitCode" content="KGM">per kilogram
> >       </div>
> > </div>
> >
> > Or you could say that the item offered is the service to dispose nuclear
> waste with the business function "provide service"
> >
> > <div itemscope itemtype="http://schema.org/Offer">
> >       <div itemprop="itemOffered" itemscope itemtype="
> http://schema.org/Product">
> >               <div itemprop="name">Nuclear Waste Disposal Service</div>
> >               <div itemprop="description">Nuclear Waste Disposal
> Service</div>
> >       </div>
> >       <link itemprop="businessFunction" href="
> http://purl.org/goodrelations/v1#ProvideService" />
> >       <div itemprop="priceSpecification" itemscope itemtype="
> http://schema.org/UnitPriceSpecification">
> >               <div itemprop="price">1000</div>
> >               <meta itemprop="priceCurrency" content="USD">$
> >               <meta itemprop="unitCode" content="KGM">per kilogram
> >       </div>
> > </div>
> >
> >
> > (I attached the name/description to the product in the first and to the
> offer in the second example, since the product entity in the first example
> is strictly speaking an arbitrary amount of nuclear waste, not its
> disposal.)
> >
> > The nice thing of this is that you can elegantly model supply and demand
> of very precisely defined services for repairing/disposing etc. specific
> objects, like "we repair Volkswagen Beetle vehicles", "Rolex Watches", "all
> cars made by BMW" (via the manufacturer property).
> >
> > Think of the cool things you could do in combination with schema:Demand
> - describe your broken watch or car, attach an image showing the object,
> and then asking for offers to fix it.
> >
> > Best
> >
> > Martin
> >
> >
> > On 19 Sep 2014, at 22:40, Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
> >
> >> Thanks Martin and Thad.
> >>
> >> So... The rest of you looks at Product as if it is ProductOrService.
> >>
> >> In that case (see it coming?): How does the rest of you look at Service?
> >>
> >> 2014-09-19 17:54 GMT+02:00 Thad Guidry <thadguidry@gmail.com>:
> >> Jarno,
> >>
> >> When you see and read schema:Product... then just think
> schema:ProductOrService in your head, instead.... like the rest of us do :-)
> >>
> >> +1  We really need to just rename that darn type, like Martin
> suggests...or create an alias type for it called
> schema:ProductOrService....and get the stakeholders to quickly understand
> either type name is allowed....Pronto.
> >>
> >> --
> >> -Thad
> >> +ThadGuidry
> >> Thad on LinkedIn
> >>
> >
>
>
>