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

On 20 Sep 2014 22:37, "Jarno van Driel" <jarnovandriel@gmail.com> wrote:
>
> 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?

Perhaps when we say a 'service' is a Product, we refer to a particular
service activity/occurrence, whereas the type Service is for the longer
term entity that does such things?

Dan

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