Re: Generic Property-Value Proposal for Schema.org

Martin,

Le 3 mai 2014 à 03:20, martin.hepp@ebusiness-unibw.org a écrit :

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

sorry not to have been clear enough

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

sure. But, as you may know, for configurations (partially defined products), properties are problematic: we need to link a product to a feature without using properties such as http://purl.org/vvo/ns#gearbox. And I hope that your proposal will allow me to make this link. It should not be a problem, as a feature *is* a PropertyValue.

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

yes

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

I was assuming that we know the description of the external (so, we know that the range of gearbox is GearboxTypeValue), and some non-standard reasoning to actually make the inference (that is, the proposal says: if propertyID is the URI of a property, then the value of the "value property" is of type in the range of propertyID)

> 
> But before people are again afraid of reinventing RDF inside schema.org: This is really an edge case,

well, we have published a few hundreds of billions of billions of such edge cases (yes 10^20) 

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

sure. I was purposely using "Feature" here to avoid ambiguity with the more general "PropertyValue" case: a product feature *is* a PropertyValue, so we can use it as object of the additionalProperty, and use its URI in the corresponding itemId

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

Martin, I know that (please don't think that I had this common fallacy ;-)) But:
- as you remark, Niklas wanted to remove propertyID (BTW, I disagree with that)
- a standard reasoner cannot (must not) do that, but a heuristic would
- as I already remarked, if you know that "this car has (=additionalProperty) a GearboxDSG", is it really necessary to say that "this car has gearbox GearboxDSG"?

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

Renault publishes data about products (range of new cars) and this means publishing data about features of products, which are Property-Value pairs. Our property-value pairs, do have URIs (in our own namespace). Then, we have a URI that correspond to a propertyID, along with a range (class of features - to each property correspond a type, the range of the property: just as vvo:GearboxTypeValue corresponds to vvo:gearbox. Actually, we're not really concerned by the property, just by the corresponding type).
Then, we have "non ideal descriptions" of the features, and of their class: typically, labels.

So, we'd like very much to have a standard type in schema.org for features, the ability to link a feature to an additionalType in an external vocabulary, and the possibility to describe features and classes of features in this external vocabulary in a "non-ideal" way (simple descriptions such as those allowed by PropertyValue).

I think that we already have everything, except for the standard type for features in schema.org.

We would be *very happy* if the new proposal would allow us to fill this gap - and it looks like it will :-)

Now, regarding actual deployment:
- we have a linked-data based service on the web that publishes the data that is used by all Renault configurator web applications. The data is available in various formats, including RDF. As a member of the team that has developed this solution and maintains it, I can say that yes, necessary changes would be included in a next release
- regarding the inclusion of markup in web pages: if we were able to say to the persons in charge that schema.org now provides an official way to describe product features, and that we can easily provide the data, that would be a strong argument. (Our data publishing service already provides HTML with RDFa markup, but this is just for demo purpose).

(if someone is interested in having a look at the data that we publish, just ask and I'll provide the links)

Best Regards,

fps

Received on Saturday, 3 May 2014 14:07:42 UTC