Re: Generic Property-Value Proposal for Schema.org

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/




On 03 May 2014, at 02:12, Niklas Lindström <lindstream@gmail.com> wrote:

> Hi Martin,
> 
> 
> On Fri, May 2, 2014 at 10:37 PM, martin.hepp@ebusiness-unibw.org <martin.hepp@ebusiness-unibw.org> wrote:
> Dear Niklas,
> 
> On 02 May 2014, at 20:10, Niklas Lindström <lindstream@gmail.com> wrote:
> 
> > Hi all,
> >
> > I do understand the case for capturing structured values describing special properties of products. The way proposed certainly makes for less normalized, precise and reusable data than simple properties with direct values enable. But it has some merit in the fact that, as Martin says, a little data goes a long way.
> 
> Thanks!
> >
> > The shape of data that this produce merits some analysis. For one, the idea to some extent resembles a mix of statement reification and structured values. More interestingly though, the pattern is similar to an effect that can be achieved by defining very specific SKOS concepts (for e.g. battery types, operating systems, screen sizes and bluetooth types), and linking to them with e.g. a productSpecification property. To me, these PropertyValue entities really look like a free-form version of such concept/topic/enum entities, with their plain text names representing their "type", rather than a generic property extension (in the RDF sense). And I see the potential in that.
> 
> Yes, one could say that my proposal is similar to "SKOS for properties" ;-)
> But after the long discussion this has triggered, I would like to downplay the proposal to the very tangible area of application for product properties and places properties. I am personally convinced that the pattern is of generic value, for it strikes a balance between preserving data structure and data semantics while minimizing the effort for a data publisher. But let's separate this aspect.
> 
> I see some generic value as well. But I think I see it from a slightly different angle. I find the notion of naming a structured value quite usable. (And I try not to think too much about the relative merit of that in relation to using dedicated properties with simple values, or to the value of datatyped RDF values (available in RDFa and JSON-LD but not in microdata). In the sense of a SKOS-like pattern, it can evolve on its own.)
> 
> What I find problematic is the very generic but somewhat contrived notion of additionalProperty, in combination with the split nature of the PropertyValue notion. It feels a bit mixed up. If instead, the structured value type was called NamedValue, and the property was called e.g. specification (applicable for products and places, and maybe other things), it seems more natural to me.
> 
> I did a search/replace for all the examples in your proposal, and I find the results quite intuitive (using Vim: %s/additionalProperty/specification/g | %s/PropertyValue/NamedValue/g). What do you think?
> 
>  
> >
> > (And although such ambiguous data can be hard to collate (and translate), it has its place, just as plain text keywords for basic website SEO have, in a primitive fashion. External enumerations (using e.g. SKOS) are often far more usable and scalable in the long term though.)
> >
> Actually, I think that processing the resulting data is less difficult as many assume, since from an NLP perspective, the space of possible interpretations is much smaller, and you will have a lot of contextual information. But the consumption of the data should not be our main concern at this point
> 
> Yes, it's true that the structure limits the complexity of processing the text (though different languages are always tricky). Also, if we're not seeking to express implicit properties in the values (in the RDF sense), but to use structured values with a contextual name, it might be easier to collate that information (since such values are more self-contained). And quite possibly easier for publishers to see when it is applicable.
> 
> 
> In general, a problem in our discussion has been that the perspective of data publication and data consumption have been mixed. Of course we all agree that the resulting data is more effort to process than standardized properties, compare
> 
> Ideal Version: External Property with Qualitative Value
> 
> <div itemscope itemtype="http://schema.org/Product">
>   <span itemprop="name">ACME Electric Anvil</span>
> ...
>   Operating Voltage: <div itemprop="http://acme.org/vocab/#voltage" itemscope
>        itemtype="http://schema.org/QuantitativeValue">
>       <span itemprop="minValue">100</span>-
>       <span itemprop="maxValue">220</span>
>       <meta itemprop="unitCode" content="VLT" > V
> </div>
> 
> with this
> 
> Variant 1: Property name instead of URI
> 
> <div itemtype="http://schema.org/Product">
>   <span itemprop="name">ACME Electric Anvil</span>
>   <div itemprop="additionalProperty" itemscope itemtype="http://schema.org/PropertyValue">
>           <span itemprop="name">Operating Voltage</span>
>           <span itemprop="minValue">100</span>-
>           <span itemprop="maxValue">250</span>
>           <meta itemprop="unitCode" content="VLT"> V
>   </div>
> </div>
> 
> or this
> 
> Variant 2: Unit as text instead of UN/CEFACT Common Code and range as a single field
> 
> 
> <div itemtype="http://schema.org/Product">
>   <span itemprop="name">ACME Electric Anvil</span>
>   <div itemprop="additionalProperty" itemscope itemtype="http://schema.org/PropertyValue">
>           <span itemprop="name">Operating Voltage</span>
>           <span itemprop="value">100-250</span>-
>           <span itemprop="unitText">V</span>
>   </div>
> </div>
> 
> or in worst case this:
> 
> Variant 3: Range and Unit in a joint field
> 
> <div itemtype="http://schema.org/Product">
>   <span itemprop="name">ACME Electric Anvil</span>
>   <div itemprop="additionalProperty" itemscope itemtype="http://schema.org/PropertyValue">
>           <span itemprop="name">Operating Voltage</span>
>           <span itemprop="value">100-250 V</span>-
>   </div>
> </div>
> 
> 
> It is obvious that the version with a dedicated property URI and a proper http://schema.org/QuantitativeValue node is easier to process.
> 
> But from a data provider's perspective, who typically has the product properties in very light-weight property-value structures, with often proprietary properties, even the step to Variant 1 makes data publication much, much simpler, because he does not have to map the local property name to a standard property URI nor determine the type of the value (quantitative, qualitative, or Boolean). That is VERY difficult from typical Web applications, even if the back-end systems (PDM/PIM) had this additional data.
> 
> >From a data consumer's perspective, however, even the lightest version
> 
> <div itemtype="http://schema.org/Product">
>   <span itemprop="name">ACME Electric Anvil</span>
>   <div itemprop="additionalProperty" itemscope itemtype="http://schema.org/PropertyValue">
>           <span itemprop="name">Operating Voltage</span>
>           <span itemprop="value">100-250 V</span>
>   </div>
> </div>
> 
> is still much easier to consume and lift than
> 
> <div itemtype="http://schema.org/Product">
>   <span itemprop="name">ACME Electric Anvil</span>
>   <div>
>           <span>Operating Voltage</span>
>           <span>100-250 V</span>
>   </div>
> </div>
> 
> And I expect that most sites could easily reach the level of Variant 1 or Variant 2.
> 
> Yes, I certainly agree that it lowers the barrier for publishers. And I do agree that you should consider the different perspectives and needs of production and consumption, to avoid confusing them. But I still think they need to be considered in conjunction.
> 
> Given the renaming suggestion above, a combination of the "ideal" and Variant 1 doesn't look too strange either:
> 
>     <div itemtype="http://schema.org/Product">
>         <span itemprop="name">ACME Electric Anvil</span>
>         <div itemprop="specification http://acme.org/vocab/#voltage"
>             itemscope itemtype="http://schema.org/NamedValue">
>             <span itemprop="name">Operating Voltage</span>
>             <span itemprop="minValue">100</span>-
>             <span itemprop="maxValue">250</span>
>             <meta itemprop="unitCode" content="VLT"> V
>         </div>
>     </div>
> 
> My point here is that a notion of a NamedValue isn't so much on a collision course with external properties as PropertyValue seems to be. In this fashion, they become more clearly complementary.
> 
> In fact, as an addition to the proposed renaming, I'd suggest to leave out the propertyID at this point. (It makes the proposal simpler. You can already provide a property with an URI as per above. And for the eclass81 prefix, I doubt that creating *another* prefix mechanism is such a good idea.)
> 
>  
> > That said, I would be *very* cautious of promoting this shape as a property extension mechanism. That would be done at the expense of using a mix of vocabularies for specialized data.
> 
> As already said, I am perfectly fine with postponing this possibility to the future and constraining this to Product and Place for the moment.
> >
> > My opinion, based on experience in both consuming data and working to unify disparate descriptions, is that, in the general case of needing specific properties beyond the core or schema.org, it would be quite valuable to apply the existing mechanism of mixing vocabularies, native to RDF and the enabler of decentralized vocabulary growth. It has been there from the start and proven extremely valuable in specific data integration scenarios. Of course, it has the downside of enabling, in Richard's words, a "cacophony of multiple vocabulary choices". But by grounding basic common terms in schema.org, we have one stable core around which other things can revolve and evolve.
> 
> > RDFa has great support for this, especially in compact form through the means of prefixes. But all of RDFa, JSON-LD and microdata support using full URIs as property names, so it can be catered for in general. (Also, JSON-LD has more powerful support through both prefix and direct term definitions in a context.)
> >
> 
> Yes, I am perfectly fine with this. If site-owners are able to publish data according to external product ontologies, like the 40+ we developed for GoodRelations, or the new GPC ontology, that is great. And my proposal does not aim at stealing this opportunity.
> 
> However, note that there are THREE bottlenecks with using external vocabularies:
> 
> 1. There must be a suitable vocabulary.
> 
> Yes. The usual chicken-and-egg problem. :) I think data consumers like search engines can drive the evolution of that by looking into usage of external vocabularies though. (Again. I do think the pendulum can slowly turn. Especially now with a core schema.org to base data shapes upon.)
> 
> 2. Site-owners must be able to map their local data to the external ontologies and publish respective data. In the past ten years, I have been able to convince just ONE site to use eClassOWL at broad scale. The problem is that the data supply for this is quite challenging.
> 
> It is definitely an effort to align local data with common models. And even more so to engage in the evolution of such models. Which we are rather aware of here. :) But there is great value in doing that work – you will think more about why the data looks the way it looks, understand your own domain in the eyes of others, and so on. It is very rewarding. But I know it's not always easy to convince organizations of this value, and to thus invest in it.
>  
> 3. Most people I speak to basically say that for their production sites, they do only what is specifified in schema.org. Unless the sponsors of schema.org explicitly endorse the use of a certain external vocabulary, this will not have a big adoption, IMO. Adding the proposed elements to schema.org in contrast will make it much easier to convince owners of this valuable data to make it available for search engines and other clients.
> 
> Yes, getting some data out is better than nothing. It is still unclear whether search engines will valuably consume and present what's already in schema.org though. Other, specialized services might more quickly make use of specialized properties – and for that, the existing URI mechanism for external properties is great. (A good example of that is WebID.)
>  
> This is not a technical issue of course, just a signal. But it will matter.
> 
> Absolutely. We're striving to send signals saying that certain patterns are or will be widely understood, consumed and built upon. I just want to make sure that we don't promote something with short-term value at the expense of long-term values which we already have worked out mechanisms for. Though as long as were seeking complementary practises to fill out the gaps, all is good.
> 
> 
> > As an example, here is what the example product table in the proposal could look like, when adding an external vocabulary (also capturing some keywords and using some external enumerations):
> >
> >     <div vocab="http://schema.org/"
> >         prefix="pto: http://www.productontology.org/id/
> >                 unit: http://qudt.org/vocab/unit#
> >                 apple: http://apple.com/def/product#">
> >       <table typeof="Product pto:IPhone_5">
> >         <caption>iPhone 5 Specifications</caption>
> >         <tr>
> >           <th>Spec</th>
> >           <th>Value</th>
> >           <th>Description</th></tr>
> >         <tr>
> >           <td>LTE Band and Mode</td>
> >           <td><span property="keywords apple:cellphoneBand">4G</span>
> >             <span property="keywords apple:cellphoneMode">LTE</span></td>
> >           <td></td></tr>
> >         <tr>
> >           <td>Battery Type</td>
> >           <td property="keywords apple:batteryType">lithium-ion</td>
> >           <td></td></tr>
> >         <tr>
> >           <td><a property="apple:productFeature"
> >               href="http://apple.com/def/feature/handheld#Built-In%20GPS">Built-In GPS</a></td>
> >           <td>Yes</td>
> >           <td></td></tr>
> >         <tr>
> >           <td property="apple:productFeature">Touch Screen</td>
> >           <td>Yes</td>
> >           <td></td></tr>
> >         <tr>
> >           <td>Operating System</td>
> >           <td property="operatingSystem">Apple iOS 7</td>
> >           <td></td></tr>
> >         <tr>
> >           <td>Screen Size</td>
> >           <td><span property="width apple:screenSize" datatype="unit:Inch">4</span>"</td>
> >           <td>Size of the screen, in inches, measured diagonally from corner to corner.
> >         </td></tr>
> >         <tr property="keywords">
> >           <td>Bluetooth Version</td>
> >           <td property="apple:bluetoothVersion">4.0</td>
> >           <td></td></tr>
> >         <tr>
> >           <td>Keyboard Type</td>
> >           <td property="keywords apple:keyboardType">Virtual QWERTY</td>
> >           <td></td></tr>
> >         <tr property="hasPart" typeof="Thing pto:Camera">
> >           <td><span property="name">Front Facing Camera</span> MP Rating</td>
> >           <td property="apple:megaPixelRating">1.2</td>
> >           <td></td></tr>
> >         <tr property="hasPart" typeof="Thing pto:Camera">
> >           <td><span property="name">Rear Facing Camera</span> MP Rating</td>
> >           <td property="apple:megaPixelRating">8</td>
> >           <td></td></tr>
> >       </table>
> >     </div>
> >
> > If Apple were to use their own properties like this, they can describe them in a page at <http://apple.com/def/product>, using:
> >
> >     <body vocab="http://schema.org/">
> >       <h1 property="name">Apple Product Vocabulary</h1>
> >       <h2>Properties</h2>
> >       <article id="batteryType" resource="#batteryType" typeof="Property">
> >         <h3 property="name">Battery Type</h3>
> >         <p property="description">The type of battery.</p>
> >       </article>
> >       ...
> >     </body>
> 
> My problem with this proposal is that it is, as far as I understand, RDFa-centric. And I think our approach should be syntax neutral.
> 
> It should be syntax neutral. You can use expanded URIs if you do a microdata version of this example (like you did above by using http://acme.org/vocab/#voltage). It may look more palatable in RDFa, but it isn't limited to it. (Except for my use of @datatype. But that was just to show that it is technically possible to do a lot with just plain values. It isn't intrinsic to the use of external properties though, and can be ignored here.)
> 
> 
> > It would be very valuable to examine what deployment problems this pattern might have encountered in the past. Perhaps understanding of it has matured in recent times? Use of embedded data in general, schema.org in particular, and the pattern of multiple types from different vocabularies has certainly increased a lot, so I would like to see if this has become more palatable. It really is quite simple:
> >
> > 1. Create a page describing your special properties.
> > 2. Use these terms within your product pages.
> 
> We have tried to foster a similar pattern in shop applications for GoodRelations, but this has really not worked well. And this proposal again mixed the perspective of data consumption and data publication. It is unnecessary to put the burden of defining a local vocabulary on a Web site, when the only purpose is to cross-reference this in other parts of the site. This is something a consuming client can do as well.
> 
> I think it is a good example of factoring your data instead of repeatedly marking up embedded labels. And I'm not entirely convinced of the high cost, although it's partly because I think the site-local vocabulary case shouldn't be that common over time. Most useful properties should be found in some vocabulary a bit more shared than that (such as Good Relations or GTIN+). As this haven't been actively promoted for schema.org though, it is untried territory for those not used to linked data in general.
> 
> Anyway, continuing the topic of external properties/vocabularies could be done independently of this proposal – especially if it is a bit more distanced from a generic property extension notion (e.g. by doing the suggested name changes).
> 
> 
> > From there, improvements can be made, such as sharing, integrating and reusing these properties across endeavours (linking them as much as possible). And of course promoting the most common of these terms for inclusion in schema.org itself (and again, linking together the "wild" sources with these new core terms).
> >
> > In practise, this requires the backers (search engines) of schema.org to promote and utilize the rich potential here. By collecting valuable external properties, and eventually enabling the most common of them to be shown in e.g. rich snippets. It requires effort of course, but since the terms are more structured than plain text, it doesn't require disambiguation heuristics, full NLP and such. (Which is the very case for structured data in pages over raw scraping and powerful text analysis.)
> >
> > Cheers,
> > Niklas
> 
> As far as I can see, my current proposal achieves basically the same with pretty straightforward markup, available in all syntaxes, and in a way that allows various degrees of granularity. Site owners will be able to preserve all granularity (e.g. if value and unit are two field) and data semantics (e.g. if they can serve a numerical range as min and max or have a public identifier for a property).
> 
> It certainly achieves something with potential. I just want to make it clear that is is complementary to external properties. With the suggested renames, it becomes a way to use structured, named values for (product) specifications, rather than a generic way for mixing plain text properties and values (which IMO confuses the notion of property in this context of structured data).
> 
> Let us make it as simple as possible for sites to expose rich product data. That should be our first priority.
> 
> It is a good priority. Let's just also make that data readily consumable, and when compromise must take place, to cater for clearly complementary alternatives.
> 
> Cheers,
> Niklas
>  
> 
> Martin
> 
>

Received on Saturday, 3 May 2014 00:36:23 UTC