W3C home > Mailing lists > Public > public-vocabs@w3.org > May 2014

Re: Generic Property-Value Proposal for Schema.org

From: Simon Spero <sesuncedu@gmail.com>
Date: Fri, 2 May 2014 15:27:38 -0400
Message-ID: <CADE8KM5ZsscqbnCJ-FTirUv6d5zNbajKY8SrUnGj9BCbxeC8nQ@mail.gmail.com>
To: Dan Brickley <danbri@google.com>
Cc: Jason Douglas <jasondouglas@google.com>, 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>
I am not a big fan of the "/" based extension mechanism in general, as
requires magical IRI deconstruction when processing instances just to
achieve the same effect as the  rdf:subPropertyOf assertions used
elsewhere.

The fact that http://schema.org/actor/lead gives a 404 rather than some
automagically generated RDF is indicative of your undisturbing  lack of
faith :-)
I'm also not a great fan of turning Dimensioned object into Strings.

There are times when using a bit of rdfs or owl is worth it.

WRT vocabularies for units and  quantities:  there's always the
NASA/TopBraid QUDT ontology, which seems to be moving on towards a new
version.

See http://qudt.org/   [ The first version was developed by Chip Masters,
who is a former #$Cyclist ].

Simon

On Fri, May 2, 2014 at 1:49 PM, 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
>
> Dan
>
>
Received on Friday, 2 May 2014 19:28:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:41 UTC