Re: Generic Property-Value Proposal for Schema.org

Hi Greg, Dan, Jason:

1. As I have already said, I have no problem with constraining the scope of this feature, at least initially, to http://schema.org/Product and http://schema.org/Place. If folks using / extending other types find this pattern useful, they can have a separate debate about the pros and cons of the pattern and make their decision independently at any later point in time. Note that historically, I called the property which is now "additionalProperty" "feature", since it was mainly intended for product features.

But I would suggest to keep the generic "additionalProperty" name for the property. This will allow us to extend the area of application of the pattern to additional types without renaming, should we want to do so later on. The combination of these two measures, i.e. generic naming (for potential broader use in the future) and narrow domain (for limiting potential side-effects and gaining experiences in a well-defined area of application) should be a fair compromise.

Bottomline: The proposal is not a generic bailout mechanism. I removed all respective mentions from the proposal page and updated the RDFa accordingly.

2. Note that the whole proposal is NOT about making a future evolution of properties in schema.org obsolete. Google and the other sponsors of schema.org will always have tight control and the power to enforce more precise properties for certain features. Simply define a new property and make it a mandatory one in the Google Structured Data Testing Tool. So this is not opening up Pandora's box of ambiguity for the future of schema.org. It rather complements existing elements so that site-owners can expose additional data that is hard to standardize and or hard to lift, but still useful with a little bit of NLP and heuristics-

3. As for any of the existing extension mechanisms:
a) slash-based specialization of existing properties
I think this does not work, for you will have to use one very generic property, like "feature", and the specialization like e.g.

http://schema.org/feature/screensize 

will be less meaningful. You loose the information that "screensize" is just a local name of the property, and not an identifier, and adding hints to a standard code for the property would require patterns with http://schema.org/Property and sameAs that will be very complex. Also, the slash-based extension mechanism is violating a core Web Architecture principle, namely that URIs should be opaque (http://www.w3.org/TR/webarch/#uri-opacity). I also foresee trouble in processing such data.

b) HTML Tables or CSV Data Modeling Support
I think that our approach should be independent of the type of presentation and the organization of visual content, so tying this to HTML tables would be mixing two orthogonal problems, and working on a CSV- or JSON / JSON-LD-specific solution will mix up the level of syntax and the level of vocabulary.
We need a solution that is independent of syntax and presentational aspects (e.g. HTML elements).

Note that the PropertyValue proposal is very different from the additionalType property. The later fixes a problem that does not existing in RDFa and JSON-LD, but I still think it was good to have, since Microdata is a popular syntax and lacked support for the use-cases.

Also please note that my proposal is not a syntactic shortcut to expose tabular data with less markup. The main motivation is to allow site-owners to add meta-data for product feature data that 

1. is hard to standardize at the level of schema.org and/or
2. that is hard to lift to any external standard for site-owners (note that Jay Myers clearly confirmed that this is an issue).

This is why we should solve this at the level of the conceptual model.


Martin


On 02 May 2014, at 20:27, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> On May 2, 2014, at 10:49 AM, Dan Brickley <danbri@google.com> wrote:
>> 
>>> On 2 May 2014 18:38, Jason Douglas <jasondouglas@google.com> wrote:
>>> Fine, but I think there's an aspect of that mechanism that would be a shame
>>> to drop, which is that it had some semantic scoping.
>>> 
>>> I think it's a bad idea to have a completely generic bailout mechanism like
>>> this.  However, I have no issue with more localized bailouts for things like
>>> product specifications or sports statistics that do have common
>>> characteristics but a lot of variety and uniqueness.  You at least have some
>>> hope of being able to do something useful with that data.  Otherwise,
>>> there's little value over a bag of words.
>> 
>> Yeah, I share the concern about having unscoped bundles of fields that
>> could mean anything.
>> 
>> I'm not a believe in the slash-based extension, at least in this case.
>> It's best used for super-properties, i.e. where the extended form
>> implies the short form:
>> 
>> Does
>> {
>> @type: Product,
>> productSpecification/screenSize : {
>>   value: 46
>>   unitCode: "CMT"
>> }
>> }
>> 
>> imply
>> 
>> { @type: Product,  productSpecification: "46"} ?
>> 
>> This would seem like an overstretch. 46 could be the number of
>> previous owners, without the qualifying info.  Whereas
>> http://schema.org/actor/lead would 'dumb down' nicely to plain old
>> '/actor'.
>> 
>> For the kind of product data Martin's talking about here, I wonder
>> whether it might be more fruitful to use something like a CSV tabular
>> form, associated as a http://schema.org/Dataset and use annotations on
>> the table structure, along lines we're spec'ing in the W3C CSV on the
>> Web group - http://www.w3.org/TR/2014/WD-csvw-ucr-20140327/
>> https://www.w3.org/2013/csvw/wiki/Main_Page
> 
> +1, although that still begs the question of what the property space is.
> 
> Gregg
> 
>> Dan
>> 
>

Received on Friday, 2 May 2014 19:55:14 UTC