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

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:48:35 UTC