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

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
>

Received on Saturday, 20 September 2014 07:39:20 UTC