Re: Generic Property-Value Proposal for Schema.org

Hi Francois-Paul:

On 03 May 2014, at 02:49, Francois-Paul Servant <francoispaulservant@gmail.com> wrote:

> Martin,
> 
> I have 2 problems with your answer.
> 
> 1)
> You explain that we cannot infer that the PropertyValue (itemId "data") is of type GearboxTypeValue - OK
> But that's not what I asked: 
> 
>>> if propertyID is the URI of a property, then the value of the "value property" is of type in the range of propertyID
> 
> So, from this:
> 
>> 	  <link itemprop="value" href="http://purl.org/vvo/ns#GearboxDSG" />VW DSG
>> 	  <link itemprop="propertyID" href="http://purl.org/vvo/ns#gearbox" />
> 
> am I correct in deducing that the type of http://purl.org/vvo/ns#GearboxDSG is in the range of http://purl.org/vvo/ns#gearbox?
I am not sure I understand the problem. First of all, in your example, you could directly use an the property and value in RDFa, JSON-LD, or even Microdata, because you have first-class citizens for both the property and the value. My proposal is mainly for the cases where at least one of the components is of lesser quality.
Then, we should distinguish schema.org semantics from RDF / RDFS / OWL semantics. From schema.org, both properties would just have a value of datatype URL. The fact that vvo:gearbox is an element of an OWL DL vocabulary which states that the range of the property is vvo:GearboxType is in principle irrelevant. Of course, a client who consumes schema.org in an RDF environment with RDFS reasoning and one that deferences all external URIs may find our that the VVO contains the statement vvs:gearbox rdfs:range vvo:GearboxType. But even then will a reasoner not *infer* that vvo:GearboxDSG is a vvo:GearboxType, because there is no triple 

s: vvo:gearbox vvo:GearboxType in the Microdata (not even when translated into RDF). Only when you write a SPARQL CONSTRUCT rule to lift this lightweight pattern to the direct triple structure, such reasoning may take place.

But before people are again afraid of reinventing RDF inside schema.org: This is really an edge case, and in real-scale scenarios, the transformation of the raw PropertyValue data into triples or equivalent structures will involve more advanced processing - heuristics, machine learning, ...


> This is not stated in the documentation about propertyID, but I think it could (and should).

For the moment, I would like to leave such edge cases out. Niklas even asked to consider removing propertyID. So let us not promote the very advanced patterns at this stage.

> 
> 2)
> Now, in the general case of PropertyValue, I understand that formally  the PropertyValue and the value are 2 different things (cf MartinHeppThePerson and MartinHeppAsAPropertyValue in an earlier message). But in the case of product features, I see no harm in saying that a feature is a PropertyValue:
> 
> <div itemtype="http://schema.org/Car" itemid="car">
> <img itemprop="image" src="station_waggon123.jpg" />
> <span itemprop="name">Station Waggon 123</span>
> <div itemprop="feature" itemscope itemtype="http://schema.org/Feature" itemid="http://purl.org/vvo/ns#GearboxDSG">
> 	  <span itemprop="propertyName">Gearbox Type</span>:
> 	  <span itemprop="name">VW DSG</span>:
> 	  <link itemprop="propertyID" href="http://purl.org/vvo/ns#gearbox" />
> </div>  
> </div>
> 
> Same number of lines as in your code, but one resource less. You can be sure that people will be at least disoriented if there are 2 distinct resources for almost the same thing.
> 

I am open to adding propertyName and using name for the value, but I think this is a minor difference to my current proposal:

<div itemtype="http://schema.org/Car" itemid="car">
<img itemprop="image" src="station_waggon123.jpg" />
<span itemprop="name">Station Waggon 123</span>
<div itemprop="additionalProperty" itemscope itemtype="http://schema.org/PropertyValue" itemid="http://purl.org/vvo/ns#GearboxDSG">
	  <span itemprop="name">Gearbox Type</span>:
	  <span itemprop="value">VW DSG</span>:
	  <link itemprop="propertyID" href="http://purl.org/vvo/ns#gearbox" />
</div>  
</div>

I would like to stick to additionalProperty and PropertyValue or NamedValue rather than feature/Feature, since we may want to use this pattern in other context later on, and feature is too narrow a wording for such uses.

In the course of the upcoming Automotive extension, we could still create a subtype and subproperty for the feature.

> BTW, we could save one line:
> 
> <div itemtype="http://schema.org/Car" itemid="car">
> <img itemprop="image" src="station_waggon123.jpg" />
> <span itemprop="name">Station Waggon 123</span>
> <div itemprop="feature" itemscope itemtype="http://purl.org/vvo/ns#GearboxTypeValue" itemid="http://purl.org/vvo/ns#GearboxDSG">
> 	  <span itemprop="propertyName">Gearbox Type</span>:
> 	  <span itemprop="name">VW DSG</span>:
> </div>  
> </div>

But then you loose the information that the type of the property is equivalent to http://purl.org/vvo/ns#gearbox. This cannot be reconstructed from the type of the object (a common fallacy - you can infer the type from the object or subject position, but you cannot (from plain RDFS) infer the property, even if you have subject and object).
> 
> The data that we publish at Renault looks like this
> 

If I understand you correctly, you are saying that Renault would be very likely adopting the proposal when available. Without asking for any formal statement from you - is that what you intended to say?

Martin

Received on Saturday, 3 May 2014 01:20:30 UTC