- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 26 Sep 2013 09:52:24 -0700
- To: public-vocabs@w3.org
Martin, there are definitely some real issues with the use of hierarchy in schema.org (e.g. the famed "volcanoes with fax numbers"). At the same time, we need to avoid going down the "third normal form" road: that is, of trying to create a perfectly defined universe of atoms. The solution is probably closer to what schema.org is today than any supposed perfection. Guha said that we should take this on a case-by-case basis. I think it's a *bit* more than that -- there may be a few high use "facets" that will help people fit their data needs into schema.org. My take would be that we should very carefully undertake some re-organizations that make schema.org easier to use, with *use* being the main goal. As to the "volcanoes with fax numbers," since all schema.org properties are optional, our problem may be solved by documentation and examples. How do we explain to people that the classes carry *possible* properties from which they choose, and all else is to be ignored? Somehow I think that using a less hierarchical display would help. Perhaps someone here with good skills in visualization could develop a "schema.org as graph" so that the hierarchy doesn't seem so dominant. kc On 9/26/13 5:37 AM, Martin Hepp wrote: > Karen, > Thanks - I think we are in agreement, see my last post. I like the idea of organizing schema.org in a more faceted style. In particular I think we should really trim down the hierarchy to the bare minimum (in fact: to true, OntoClean[1] subsumption relations). Currently, I have the impression that we have subtype relations that are often yet not always valid. > > Those also clutter the list of properties. > > > See for instance the impact of the position of > > http://schema.org/CreativeWork > > on many other types, like > > http://schema.org/Diet > > Since CreativeWork and all of its properties is so high in the hierarchy, it adds many not really relevant properties along the hierarchy. > > For instance, "Diet" has the properties > > genre Genre of the creative work > learningResourceType The predominant type or kind characterizing the learning resource. For example, 'presentation', 'handout'. > educationalUse The purpose of a work in the context of education; for example, 'assignment', 'group work'. > isFamilyFriendly Boolean Indicates whether this content is family friendly. > > which are not too relevant. > > So we could simplify the type hiearchy and instead add a notion of "popular facets" and then listing facets (e.g. roles) that are useful to add. > > > Martin > > > > On Sep 25, 2013, at 2:54 PM, Karen Coyle wrote: > >> Martin, >> >> I realize that you've asked Dan and Guha, but I've been thinking about this same question (your a) b)). Without getting overly philosophical, I think we have a difference between "essence of the thing" - that is, what you need to describe it as "it" - and situational or functional description. Audiobook needs /Book and /Audiobook to describe it 'qua' audiobook, but situationally could also be a product. Since conceivably one could describe an audiobook apart from its being a product, then product isn't a necessary aspect of audiobook. >> >> This fits in to some faceted classification models where there is a primary facet that is the essence of the thing, and then additional facets for those "accidental" or "situational" aspects that apply to particular instances. In classification these tend to be "universals" (place, time, etc.). They can be applied to any "thing" in the vocabulary. In the case of schema.org I could imagine using both /Product and /Accessibility as facets, allowing them to be used wherever they are relevant. There has been some discussion of terms for measurements, and that, too, is a likely candidate as a facet. >> >> In a more structured vocabulary, facets would be aspects that would never stand alone, since they modify other concepts. That isn't the case today for /Product, but schema.org isn't strict so I don't see that as an issue. >> >> kc >> >> On 9/25/13 12:40 AM, Martin Hepp wrote: >>> Hi Karen, >>> good that we have consensus. >>> >>> Dan, Guha: I think the issue of whether multi-type entities should be solved >>> >>> a) at markup time or >>> b) in the vocabulary >>> >>> is of generic relevance - do you have an opinion on that? >>> >>> I think that for types that are not disjoint but also only loosely related (like an AudioBook used as a Product), it is much cleaner and flexible to recommend using both types at markup time. >>> >>> This also decouples the evolution of such needs / use cases from the evolution of the schema.org spec - site owners do not have to wait for an update to schema.org, and search engines can learn from the appearance of new patterns. >>> >>> Martin >>> >>> On Sep 24, 2013, at 9:07 PM, Karen Coyle wrote: >>> >>>> >>>> >>>> On 9/24/13 11:40 AM, Martin Hepp wrote: >>>>> Hi Karen, >>>>> as already posted earlier today: >>>> >>>>> >>>>> Simply use the offers property from Product or the itemOffered property from offer and make the AudioBook (or other object) of type AudioBook AND Product. >>>> >>>> Yes, thanks, Martin. I saw that on your reply to Dan and that seems to be exactly what we need. >>>> >>>> kc >>>> >>>> -- >>>> Karen Coyle >>>> kcoyle@kcoyle.net http://kcoyle.net >>>> m: 1-510-435-8234 >>>> skype: kcoylenet >>>> >>> >>> -------------------------------------------------------- >>> martin hepp >>> e-business & web science research group >>> universitaet der bundeswehr muenchen >>> >>> e-mail: hepp@ebusiness-unibw.org >>> 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 >>> >>> Check out GoodRelations for E-Commerce on the Web of Linked Data! >>> ================================================================= >>> * Project Main Page: http://purl.org/goodrelations/ >>> >>> >>> >>> >>> >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net http://kcoyle.net >> m: 1-510-435-8234 >> skype: kcoylenet >> > > -------------------------------------------------------- > martin hepp > e-business & web science research group > universitaet der bundeswehr muenchen > > e-mail: hepp@ebusiness-unibw.org > 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 > > Check out GoodRelations for E-Commerce on the Web of Linked Data! > ================================================================= > * Project Main Page: http://purl.org/goodrelations/ > > > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Received on Thursday, 26 September 2013 16:52:58 UTC