Re: Generic Property-Value Proposal for Schema.org

Dear Martin,

some remarks regarding your proposal.

Regarding the motivations:
- I agree that there is a strong motivation for such a proposal, and you name it in your second design principle: "No Lifting and Cleansing Barrier: Do not force site owners to lift or cleanse existing data."
You may have very precise data describing your products in a table that you could very well publish it as they are, but it is difficult to map columns and cells to external vocabularies (if such vocabularies exist). It should be possible to lift the data later.

- I'm less convinced by the argument "generic extension mechanism for properties at the level of schema.org". As you note, using external properties is a problem in microdata. But it is not the case in RDFa or in JSON-LD: RDF, by itself, provides a generic pattern for exposing characteristics for entities. I don't think that it is a big effort for a site owner to mint a URI for an additional property.

Regarding the proposal itself: in order to avoid having to define many properties in schema.org, you propose an alternative, simplified way to write s p o triples when describing a resource s, using one and only one property, schema:additionalProperty, whose range is schema:PropertyValue. Basically, PropertyValue is a pair (property,value). You describe a PropertyValue using a few properties: schema:name, schema;value, schema:unitText, etc.

I would keep and make explicit the (property,value) pair structure, using two dedicated properties (say): schema:property and schema:object, both with domain PropertyValue
Why? to make it possible to easily lift data published using schema:additionalProperty, in bulk.

Let's take some of your examples to explain it:

<div itemtype="http://schema.org/Product">
	<img itemprop="image" src="camera123.jpg" />
	<span itemprop="name">Digital Camera 123</span>
	<div itemprop="additionalProperty" itemscope itemtype="http://schema.org/PropertyValue">
		<span itemprop="name">Approx. Weight</span>
		<span itemprop="value">450</span>
		<span itemprop="unitText">gram</span>
	</div> 
   	<div itemprop="additionalProperty" itemscope itemtype="http://schema.org/PropertyValue">	  
		<span itemprop="name">Interface</span>:	  
		<span itemprop="value">USB</span>
	</div>
</div>

that is in turtle (for lisibility):

[	a schema:Product;
	schema:image x:camera123.jpg;
	schema:name "Digital Camera 123";
	schema:additionalProperty [
		a schema:PropertyValue;
		schema:name "Approx. Weight";
		schema:value "450";
		schema: unitText "gram"
	];
	schema:additionalProperty [
		a schema:PropertyValue;
		schema:name "Interface";
		schema:value "USB";
	]
]

(note BTW that your use of schema:name for the PropertyValue is a bit incorrect, as you do not use it to label the PropertyValue pair, but the property. A schema:name for the second of the examples should probably be "Interface: USB" - but Ok, that's not important)

I suggest to write instead:

[	a schema:Product;
	schema:image x:camera123.jpg;
	schema:name "Digital Camera 123";
	schema:additionalProperty [
		a schema:PropertyValue;
		schema:property [
			schema:name "Approx. Weight"
		];
		schema:object [
			schema:value "450";
			schema: unitText "gram"
		]
	];
	schema:additionalProperty [
		a schema:PropertyValue;
		schema:property [
			schema:name "Interface"
		];
		schema:object [
			schema:value "USB";
		]
	]
]

Not really different, not more difficult to produce, arguably more blank nodes.
The point is that in many cases, you have URIs for the values, or you can easily mint them from your own codification. And you can therefore easily produce, say:

[	a schema:Product;
	schema:image x:camera123.jpg;
	schema:name "Digital Camera 123";
	schema:additionalProperty [
		a schema:PropertyValue;
		schema:property foo:approxWeight;
		schema:object [
			schema:value "450";
			schema: unitText "gram"
		]
	];
	schema:additionalProperty [
		a schema:PropertyValue;
		schema:property foo:interface;
		schema:object foo:USB
	]
]
foo:approxWeight schema:name "Approx. Weight".
foo:interface schema:name "Interface".
foo:USB schema:value "USB".

The advantage here is that this data can be later improved, for instance stating:

foo:approxWeight rdfs:subPropertyOf schema:weight.
foo:USB owl:sameAs dbpedia:USB.

this can be done without any impact on the source systems, on the actual production of the data, or on data that are already published: you can write the statements above once and lift all corresponding records at once.

A question we would then ask is the question of rules than can be linked to the use of schema:additionalProperty. Is it equivalent to state: 
s schema:additionalProperty [
	schema:property p;
	schema:object o
]

and s p o?

Also note that in many cases, you actually don't care about the property. An example describing cars:
[	a vso:Vehicle;
	schema:additionalProperty [
		schema:object [ schema:name "Sunroof" ]
	],[
		schema:object dbpedia:Diesel
	]
]

but we probably would prefer to write something like:
[	a vso:Vehicle;
	schema:feature [ schema:name "Sunroof"],
	schema:feature dbpedia:Diesel
]
	
Best Regards,

fps

Le 29 avr. 2014 à 11:42, martin.hepp@ebusiness-unibw.org a écrit :

Dear all:

I have just finalized a proposal on how to add support for generic property-value pairs to schema.org. This serves three purposes:

1. It will allow to expose product feature information from thousands of product detail pages from retailers and manufacturers. 
2. It will simplify the development of future extensions for specific types of products and services, because we do no longer need to standardize and define all relevant properties in schema.org and can instead defer the interpretation to the client.
3. It will serve as a clean, generic extension mechanism for properties in schema.org

The proposal with all examples is here:

   https://www.w3.org/wiki/WebSchemas/PropertyValuePairs

Your feedback will be very welcome.

Best wishes / Mit freundlichen Grüßen

Martin Hepp
-----------------------------------
martin hepp  http://www.heppnetz.de
mhepp@computer.org          @mfhepp

Received on Wednesday, 30 April 2014 07:15:10 UTC