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

Martin,

 I think they are more alike than that. Both are mechanisms that kind of
reify a triple. In one case, it is to make additional statements about the
triple (like further qualifying the relationship) and in the other case, it
is because the arc is not in the vocabulary.

 In fact, one of the uses of roles is to further elaborate the relation.
e.g., JoeMontana not only played for the 49ers, he was the quarterback. We
don't have an attribute called quarterBackOf but the role object can be
reused for this purpose.

guha



On Fri, May 9, 2014 at 11:49 AM, martin.hepp@ebusiness-unibw.org <
martin.hepp@ebusiness-unibw.org> wrote:

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