Re: Generic Property-Value Proposal for Schema.org

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 18:28:17 UTC