- From: Phil Barker <phil.barker@hw.ac.uk>
- Date: Fri, 27 Sep 2013 09:34:47 +0100
- To: public-vocabs@w3.org
I wrote this over the summer prompted by a different discussion. I didn't send it then as it seemed a bit too tangential. But since we've set of on that tangent... I have a comment that isn't about any specific property or extension to the schema vocabulary. The comment is about the documentation of schema.org in general, Paul's suggestion illustrates the issue nicely On 13/06/2013 07:59, Paul Watson wrote: > > Rather than being specific to VisualArtwork I'd suggest you amend your > proposal so that ColorPalette be a property of Thing to give the > opportunity for people to describe the colours of things beyond visual > artwork. > My concern is that the higher level classes in schema (Thing, CreativeWork etc) are getting a lot of properties from different specialist domains. I don't think that is a problem per se, in fact I think it is correct. I was involved the Learning Resource Metadata Initiative that added its fair share of these properties to CreativeWork. Also I don't wish to imply that Paul's suggest is problematic. But it does mean that anyone coming to the schema.org documentation for Thing or CreativeWork will be presented with a long list of properties, many of which while being self-evidently important and clearly defined to those from the perspective of some specialist domain will be pretty impenetrable to the general user. My suggestion is that in some way the documentation reflect which properties are "core" and which have been added for some domain specific purpose. I know it is difficult to say what constitutes the cross domain core, but I think it would be relative easy and useful to group together those properties of, say, CreativeWork that were added because they are specifically relevant to resources being described for use in the context of learning, or those properties that are specifically relevant to the description of legal aspects of a resource. This might help users focus their attention on those properties relevant to them and help them understand what the descriptions mean. Alternatively, working vice-versa it may be useful to suppress those properties of, say, a Diet or Volcano that have been inherited but really aren't particularly applicable to the specific class in question. Phil On 26/09/2013 17:52, Karen Coyle wrote: > 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/ >> >> >> >> >> > -- <http://www.icbl.hw.ac.uk/~philb/> ----- Sunday Times Scottish University of the Year 2011-2013 Top in the UK for student experience Fourth university in the UK and top in Scotland (National Student Survey 2012) We invite research leaders and ambitious early career researchers to join us in leading and driving research in key inter-disciplinary themes. Please see www.hw.ac.uk/researchleaders for further information and how to apply. Heriot-Watt University is a Scottish charity registered under charity number SC000278.
Received on Friday, 27 September 2013 08:35:45 UTC