Roles vs. Property- Value-Pairs / was Re: Finalizing Schema.org "Roles" design

Hi all:

After some checking: I do not think that there is a lot of overlap between the roles proposal and the property-values proposal:
1. The roles proposal is mainly for expressing temporally-bound type membership or relationship information. 
2. The property-value proposal is for allowing site-owners to expose product and places properties in the form of property-name and value pairs, preserving common categories of meta-data in a flexible way, so that sites can easily expose such data from their current HTML templates.

Even if there were some abstract commonalities between the two, we should keep in mind that schema.org is mostly a vocabulary for publishers, not for data consumers. This means that our choices of names for conceptual elements and conceptual structures should be centered on Web developer needs.

I doubt that an average developer will find it natural to use http://schema.org/Role to express a non-standard product property.

We could try to make http://schema.org/PropertyValue a subtype of http://schema.org/Role. The main reason why I am hesitant to merge the two is, however, is that http://schema.org/PropertyValue will most frequently be used with a given product or place as the subject entitx, while http://schema.org/Role takes a birds-view perspective on a factual statement. You make a statement about the triple of a subject, a property, and an object.

So hastily sketched, a combined approach would look as follows:

First, my current proposal:

foo:Product schema:additionalProperty [a schema:PropertyValue ;
					schema:name "input voltage" ;
					schema:value 110;
					schema:unitText "volts" . ] .

Any version based on the roles proposal would work form an outside view on the entity:
(assumed that schema:PropertyValueRole became a subtype of http://schema.org/Role):

foo:PropertyValue1 a chema:PropertyValueRole;
	schema:roleSubject foo:Product ;
	schema:roleProperty [a schema:Property ;
			       schema:name "input voltage"  . ] ;
	schema:roleObject [a schema:QuantitativeValue ;
			     schema:value 110 ;
			     schema:unitText "volts" . ].

Don't be fooled - in Turtle, this looks kind of appealing. But in Microdata and RDFa it is much more difficult to model such information if your main entity is the product. You will have to use @itemref/@itemid or @about, which is error-prone.

Also, in the end, we will have to expand http://schema.org/StructuredValue by the properties that I suggested for http://schema.org/PropertyValue, because site owners will NOT be able to automatically decide for each property-value whether the roleObject is a QuantitativeValue, a QualitativeValue, or a plain literal. So we need, in any case, an ambiguous super-type for such values. 

I do not see a big difference whether we have 
a) my original proposal or

b) a common approach with
- a subtype of schema:Roles named schema:PropertyValueRole (maybe with propertyID as a new property)
- schema:StructuredValue augmented with minValue, maxValue, unitText, unitCode 

Conceptually, the latter looks a bit cleaner, but you introduce the likely big source of errors that the modeler who works from the main entity (e.g. the product) has to link TO this Roles / PropertyValueRole instance via schema:roleSubject. While this might be doable  -- even in Microdata with the new InverseProperties proposal --, this is a prime source of poor data quality, same as rel/rev in RDFa.

As for the fears that the property-value pairs puts the whole Semantic Web at risk: In terms of data consumption, it does not really matter whether we go that route from one common branch or from two. I think that for naming reasons, we need a specific type for property-values anyway.

Martin

Received on Friday, 9 May 2014 18:50:21 UTC