Re: why Vehicle subClassOf Product ? (also: Commercial, Economic)

Very much in agreement with you say Martin, yes. :)

On Thu, Mar 26, 2015 at 9:47 AM, Martin Hepp <martin.hepp@unibw.de> wrote:

> Aaron: I think we are in agreement regarding the conclusion: Because MTEs
> are slippery ground, at least currently, we should keep Vehicle where it is
> now.
>
> I also agree that it would be very desirable if the sponsors of schema.org
> could properly support and document the use of MTEs. That is in the long
> run better than gradually moving more and more types beneath Product; and
> we also need MTEs for ProductModel cases anyway.
>
> Martin
>
> --------------------------------------------------------
> 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
>
>
>
>
>
> On 26 Mar 2015, at 17:41, Aaron Bradley <aaranged@gmail.com> wrote:
>
> > And since partial confirmation by GWT can hardly be considered proof
> that it's fine to use MTEs it would indeed be very nice if all the sponsors
> could inform us where they stand in regards to MTEs - something which is
> long overdue IMHO.
> >
> > Big +1 to this.  From a webmaster's perspective the value in using
> structured data markup to improve the search engines' understanding of the
> resources being provided to them obviously hinges on whether or not the
> search engines can properly process and understand the markup being
> provided to them.
> >
> > "I hope ... that practically maybe ... can happen ... it is unclear ..
> room for trouble"
> >
> > Selective pulling of qualifiers not directed at you, Martin, but by
> means of illustrating that in regard to MTEs none of the sponsors, AFAIK,
> have said so much as one word on employing them, leaving everyone guessing
> and webmasters with exactly no confidence about the impact of employing
> MTEs.  For my part I shy away from using MTEs because they may well do more
> harm than good.
> >
> > In light of this, I think it's a very bad idea indeed to have any
> examples that employ MTEs in schema.org examples until there's clarity
> surrounding this, e.g. [1]:
> >
> > <body vocab="http://schema.org/" itemscope itemtype="
> http://schema.org/VideoGame http://schema.org/MobileApplication">
> >
> > Is this robust syntax for Google?  Bing?  Yahoo?  Yandex?  Who knows!
> Try using the flagship product of that first-listed entity...
> >
> https://www.google.com/search?q=multiple%20entities%20schema.org&pws=0&hl=en&num=10
> > ... and the results are largely circular, pointing straight back to the
> discussions that take place here.
> >
> > For the record, Google has a page [2] with a heading "Multiple entities
> on the same page" that speaks not at all to syntax, but unhelpfully says
> that "When you have multiple entity types on a page, we recommend you mark
> up all entities on that page" without providing either guidance or examples
> that illustrate how to do this in a Google-approved fashion.
> >
> > If this is indeed "a collection of schemas that webmasters can use to
> markup HTML pages in ways recognized by major search providers" then don't
> provide me with HTML that is not recognized by the major search providers,
> or that nobody knows is recognized by the major search providers.
> >
> > [1] http://schema.org/VideoGame
> > [2] https://developers.google.com/structured-data/policies
> >
> >
> > On Thu, Mar 26, 2015 at 8:52 AM, Martin Hepp <martin.hepp@unibw.de>
> wrote:
> >
> > On 26 Mar 2015, at 15:58, Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
> >
> > > "Thus an MTE in Microdata cannot formally have the properties from
> that second type."
> > >
> > > Yes and no. Yes in a sense that the microdata specs say state that as
> long as the types are from the same vocabulary all is fine:
> > >
> > > The itemtype attribute, if specified, must have a value that is an
> unordered set of unique space-separated tokens that are case-sensitive,
> each of which is a valid URL that is an absolute URL, and all of which are
> defined to use the same vocabulary. The attribute's value must have at
> least one token.
> > >
> >
> > Yes, but note that there are two issues:
> >
> > 1. You must use the Microdata way of multi-typed entities
> (space-separated list of types); additionalType will formally not work
> (practically maybe).
> >
> > 2. Properties in Microdata are bound to a type; the notion of global
> property identifiers is specific to schema.org and RDF environments. It
> can happen that the meaning of the same property is different for two
> types. Then, if that property is attached to a multi-typed entity, it is
> unclear to which definition and which role of the entity it belongs.
> >
> > I do not think this is currently a problem, due to the global definition
> of properties in schema.org, but I have been advocating for long to
> weaken that notion of a globally consistent vocabulary. Should we once
> follow this route, the MTE approach can cause trouble.
> >
> > Also, validator can run into problems if cardinality constraints or
> ranges for properties differ by the entity type. For instance, something is
> a Book and a Product, and a book must have a weight, while a Product must
> have one (hypothetically).
> >
> > Now, a validator must decide which requirement prevails. Without
> overseeing all possible cases right now, I assume there is room for trouble.
> >
> > > No in sense that this wouldn't work if one uses multiple vocabularies.
> Which is something we might consider trying to change as I think it's weird
> that RDFa and JSON-LD do allow this, making this situation confusing for
> publishers to say the least.
> >
> > Yes, fixing Microdata would help. Or publishing a note that says that
> the sponsors of schema.org consider additionalProperty fully equivalent
> to rdf:type and tolerate multi-type entities on this basis.
> >
> > Martin
> >
> > >
> > > 2015-03-26 15:48 GMT+01:00 Martin Hepp <martin.hepp@unibw.de>:
> > > In general I agree.
> > >
> > > Note, however, that MTE in microdata are problematic, because
> additionalType does not formally make the properties from that second type
> valid properties for the entity, according to the Microdata spec, because
> the vocabulary of the main type defines the finite list of properties
> available for that type. Thus an MTE in Microdata cannot formally have the
> properties from that second type.
> > >
> > > I think this is more of a problem of Microdata than schema.org and I
> hope that Google and all others are tolerating such additional properties,
> though.
> > >
> > > Martin
> > >
> > > --------------------------------------------------------
> > > 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
> > >
> > >
> > >
> > >
> > >
> > > On 26 Mar 2015, at 15:44, Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
> > >
> > > > "IF we can establish it as a standard that products are multi-typed
> entities and IF all major consumers of schema.org markup can process this"
> > > >
> > > > I know from Google's Webmaster Tools reports that Google parses MTEs
> quite fine, although I can't tell from those whether they 'understand' them
> as well or use MTE data for their search results.
> > > >
> > > > And since partial confirmation by GWT can hardly be considered proof
> that it's fine to use MTEs it would indeed be very nice if all the sponsors
> could inform us where they stand in regards to MTEs - something which is
> long overdue IMHO.
> > > >
> > > > 2015-03-26 15:26 GMT+01:00 Martin Hepp <martin.hepp@unibw.de>:
> > > > IF we can establish it as a standard that products are multi-typed
> entities and IF all major consumers of schema.org markup can process
> this, then it would indeed good to
> > > >
> > > > - move all subtypes of Product up to a new branch of Thing
> > > > - move up all properties of Product that are not tied to the Product
> role up to that subtype(s) of Thing (e.g weight)
> > > >
> > > > The historic reason for having Car etc. below Product was that
> > > >
> > > > - we could not rely on multi-typing, because in Microdata,
> multi-typed entities are not fully supported (we have additionalProperty
> and multi-types from the same vocab are in general okay, but there are
> unresolved problems with properties in this case)
> > > >
> > > > - human users are more likely to use such types properly if they see
> all properties that apply, i.e. such from the nature of the product and
> from the product role.
> > > >
> > > > GoodRelations has always relied on the multi-type approach, but in a
> bit more complicated manner, see
> > > >
> > > >
> http://wiki.goodrelations-vocabulary.org/Documentation/Extensions (a bit
> outdated)
> > > >     http://wiki.goodrelations-vocabulary.org/Vocabularies
> > > >
> > > > But as said, I am happy to clean this up if the two preconditions
> above are met.
> > > >
> > > > Martin
> > > >
> > > > --------------------------------------------------------
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 26 Mar 2015, at 14:35, ☮ elf Pavlik ☮ <
> perpetual-tripper@wwelves.org> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > As I understand Product acts as Class for adding e-commerce aspect
> to
> > > > > other Things. Most likely to use it with "@type": ["Book",
> "Product"] or
> > > > > additionalType when used in microdata.
> > > > >
> > > > > I don't understand why Vehicle landed as subClassOf Product? I also
> > > > > don't understand which other things may end up subclassing Product
> in
> > > > > the future and which will for example subclass CreativeWork or
> Place.
> > > > >
> > > > > IMO Vehicle, just as Place could directly subclass Thing. Or we
> could
> > > > > also add Tangible class to deal in a future with with Device etc.
> (e.g.
> > > > > http://schema.org/MedicalDevice)
> > > > >
> > > > > It reminds me about my question long time ago about POI (Point Of
> > > > > Interest). Which also doesn't make that much sense in class
> hierarchy
> > > > > but could similar as Product serve as a class to use in addition to
> > > > > other classes.
> > > > >
> > > > > I haven't worked with ruby programming language for quite some
> time, but
> > > > > in some ways I see similarity to Class vs. Module (besides many
> other
> > > > > differences from Object Oriented Programming, single parent doesn't
> > > > > apply here as well)
> > > > > This answer has relevant example which happens to use a Vehicle
> > > > >
> http://stackoverflow.com/questions/1282864/ruby-inheritance-vs-mixins/1282895#1282895
> > > > >
> > > > > In a way Product sounds to me as something more in direction of
> > > > > 'Commercial' or broader 'Economic'.
> > > > >
> > > > > Thoughts?
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>

Received on Thursday, 26 March 2015 16:50:30 UTC