Re: Generic Property-Value Proposal for Schema.org

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 (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 <
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 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 without being successful at getting the to deploy
> Linked Open Data. It also fits the generic 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
> phone:   +49-(0)89-6004-4217
> fax:     +49-(0)89-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/
>
>
>