- From: Dan Brickley <danbri@google.com>
- Date: Fri, 2 May 2014 18:49:38 +0100
- To: Jason Douglas <jasondouglas@google.com>
- Cc: Aaron Bradley <aaranged@gmail.com>, kevin.polley@mutualadvantage.co.uk, "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>, W3C Web Schemas Task Force <public-vocabs@w3.org>, Jay Myers <jay.myers@bestbuy.com>, Mike Bergman <mike@mkbergman.com>
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
Dan
Received on Friday, 2 May 2014 17:50:06 UTC