Re: Generic Property-Value Proposal for Schema.org

How about schema:hasA with a range of schema:Thing or Text?

Jeff

On May 3, 2014, at 11:38 PM, "Niklas Lindström" <lindstream@gmail.com<mailto:lindstream@gmail.com>> wrote:

Martin, all,

It still seems to be unclear what this mechanism really represents. What is the nature of these named composite values? Do they represent a conflation of a property and a value, or just a textually typed structured value? And with that answered, what is the (necessary) meaning of 'additionalProperty'?

The name 'additionalProperty' certainly seems problematic. This mechanism does not appear equivalent to the 'additionalType' workaround, which is required to overcome a limitation in microdata. It does however, appear to be about representing undefined properties in general. It does not have to be so.

I think it would be troubling to attempt the creation of a generic solution that could catch all cases of "unknown" properties. I've seen enough hand-waving in XML (and other formats) to know how hard such data can be to deal with (also for producers). It makes for an artificial mechanism, hard to understand and thus being inconsistently used (and soon enough, ad-hoc conventions and sketchy microsyntaxes tend to appear). Also, since values would seem like semi-reified statements, with a conflated composite of property and value, it'd start to blur the notion of what a property is (an effective device for capturing precise data in a direct, flat and simple manner).

However, and most importantly, the proposal really only deals with capturing certain kinds of values. What these values have in common is that they, in themselves, represent a nameable characteristic – an *aspect* – of a thing, particularly a product. These structured values can be composite (minValue, maxValue, unit and so forth). The proposal doesn't alter this existing StructuredValue. It just adds a name (text label) indicating the nature of this aspect a little. If this nature is *intrinsic* to the value (and not just one of many roles it could have), then we're on reasonably solid ground. And then this seems like a valuable mechanism that shouldn't threaten the integrity of properties, nor to the structured values it captures.

(Martin and Jarno do make a strong case of this being the limit of what many publishers today are willing to mark up. That state of things is rather unimpressive from a consumer's perspective in principle (and lamentable when striving for unification in general). But there may not be enough direct incentive yet to convince everybody to go look for, or mint, properties for all of these details. This does not have to be an all-or-nothing. Like Martin, I am sure we can find ways to bridge this gap.)

As Francois-Paul points out, the name of these values seems to represent the *type* of the value just as much as it indicates a relation to it. This is an important observation. I think Richard Cyganiak stated something similar a while ago: that if the value is distinct enough, the relation doesn't need to be very specific. (This is why Dublin Core terms like hasPart/isPartOf are so effective and relatively popular.)

Consider the example values in the proposal:

- 450 grams of approximated weight
- 100-250 volts of Operating Voltage
- 30 ft. Wifi range
- 100-6400, 12,800 ISO Sensitivity
- 500 LTR of Luggage Capacity
- Ethernet and USB Interfaces
- 5 liter of fuel consumption per 100 km
- A sensor size of 23.3 mm x 15.4 mm

Of course there is potential value in having dedicated properties for them. But they are already structured (composite) values. And none of them play multiple roles. They are all aspects of a product, and the name of this aspect reasonably belongs to them (it's a type hint, if you will). They are not reusable as other things (the same 30 ft. would not also be the approximated distance you can throw the device – that would be *another* aspect with an approximated throwing distance value).

Thus, it isn't necessary to define a specific property in schema.org<http://schema.org> (or at all), to get some kind of usage from these values. As long as these named structured values do represent themselves (and not a mix of a property (in the structured data/RDF sense) and its value), you can further specify the relation (and the type) using external vocabularies if you want to, without changing the shape of the data.

This is my main point. I think a design is possible that maintains the integrity of the commonly uncontrolled but structured values, so that additional precision can be added if desired, without requiring a change in shape. It may be that instances of named StructuredValues are odd creatures in an ideal world. (I am certainly aware of how I've shifted my mind to write this.) But so are SKOS concepts ("strings masquerading as things", as Jeff Young put it). They do have their uses though, since there is a limit to how much semantic engineering and ontological normalization we can collectively muster. (And since this is more about useful communication than a perfect rational reality, I think that is acceptable.)

Therefore, I maintain my recommendation of renaming 'additionalProperty'. Perhaps to 'aspect'? A dictionary defines that as "a particular part or feature of something". Sounds generally applicable. For the range of that, I can imagine Intangible, since many of its subclasses could be quite useful as values (not just a named StructuredValue). I also maintain that NamedValue is better than PropertyValue, since the whole point is to add a name to a StructuredValue. (Martin, I noticed you wrote NamedProperty in the wiki. Did you really mean NamedValue?)

I still find propertyID a bit problematic. If you have an external property URI, just use it as a property (alongside additionalProperty/aspect). Same thing if you have a class URI (use it as an additional type). Francois-Paul, wouldn't that work for Renault's case? But I do see why some kind of property might be needed, when you have a code from a system which is neither a URI nor a plain label. Maybe <http://schema.org/codingSystem> can be modified to be usable here too (e.g. domainIncludes StructuredValue)? That might be more for the proposed SKOS integration work though (which could play nice together with this).

Cheers,
Niklas



On Sat, May 3, 2014 at 2:35 AM, martin.hepp@ebusiness-unibw.org<mailto:martin.hepp@ebusiness-unibw.org> <martin.hepp@ebusiness-unibw.org<mailto:martin.hepp@ebusiness-unibw.org>> wrote:
Hi Niklas:

Quickly:

- I in favor of renaming PropertyValue to NamedValue. What do the others think?

- I would like to keep propertyID, because
a) it reduced many of our efforts for using existing such standards for schema.org<http://schema.org> to convincing them to promote an official prefix, which is easy as compared to making them commit to a URI space in their domain name (which is often a tedious process and does not guarantee that this URI will space will be stable in any way). It would require a deeper discussion of BMEcat, eClass, and other standards to explain how much simpler the lives of many people in this space will be if we can find a way to leverage those efforts for schema.org<http://schema.org> without being successful at getting the to deploy Linked Open Data. It also fits the generic schema.org<http://schema.org> of allowing people to use identifiers directly without expecting someone to mint a URI.

b) there are cases in the automotive industry where there are brand-specific identifiers for properties that will be valuable to keep.

I think one property more or less will not make the difference ;-)
- As for additionalProperty vs. specification, I would like to keep additionalProperty.

In general, it is interesting how much activity such a small proposal has triggered, compared to the fact that many important other proposals on the stack are progressing rather slowly ;-)


Best wishes / Mit freundlichen Grüßen

Martin Hepp

-------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  martin.hepp@unibw.de<mailto:martin.hepp@unibw.de>
phone:   +49-(0)89-6004-4217<tel:%2B49-%280%2989-6004-4217>
fax:     +49-(0)89-6004-4620<tel:%2B49-%280%2989-6004-4620>
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================
* Project Main Page: http://purl.org/goodrelations/