- From: Martin Hepp <martin.hepp@unibw.de>
- Date: Thu, 26 Mar 2015 16:52:33 +0100
- To: Jarno van Driel <jarnovandriel@gmail.com>
- Cc: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>, W3C Web Schemas Task Force <public-vocabs@w3.org>, Gregg Kellogg <gregg@greggkellogg.net>
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 15:53:23 UTC