- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 28 Feb 2013 08:26:06 -0800
- To: public-schemabibex@w3.org
I'm going to try this again, hopefully with more clarity (not less :-)) - On 2/24/13 11:28 AM, Wallis,Richard wrote: > Not sure what you mean by this - additionalType was added to Schema because of the need to describe things to be of more than one type, which many real word things are. Unfortunately Microdata has a limitation in this area, which RDFa does not, so this approach became a basic part of the vocabulary which we are proposing to extend. I see no reason not to use all of the vocabulary. > Like all schema.org properties, additionalType is optional in instance data. OTOH, Itemtype is required for the data to be recognized as microdata - at least, that's how it tests out at the Google rich snippets validation: the rich snippets won't show up properly without it. Therefore, we need to think about what itemtypes are essential (as Ed said in an earlier email) since we can't be confident that additionalTypes will be used. Thus, if we think that eBook should be distinct from Book, then it will need to be an itemtype. If instead we think that the distinction isn't important (or is optional) then we don't need an itemtype for eBook -- we would instead use Book and some folks will include the optional additionalType for eBook. This is the distinction I am making -- that additionalType is optional, while itemType is not. Note that the Product folks have taken a very different approach from the rest of schema.org - there are no sub-classes under Product for the different product types, while there are lots of sub-classes under "Event" and "Place" and the medical categories. etc. Instead the Product folks are relying on the additionalType added to the very generic "SomeProducts." This means that although it is called "additionalType" in many cases it will be the only real "type" information included, other than saying that it is a product. In examples that don't have an additionalType the only thing identifying the product is the name or the description. By analogy, one could have no sub-classes under CreativeWork and use the productOntology to distinguish the types of creative works. That isn't the approach that was taken for CreativeWork or for classes other than Product, however. kc >> This is one of my concerns with the product ontology: if the information is essential to the microdata markup, it cannot be ONLY in the additionalType. So where there is something like: >> >> Format: Audiobook on CD<br/> >> >> ... if we think that "CD" is an important bit of information for rich snippets or searching, then that needs microdata markup. The additional type statement: >> >> <link itemprop="additionalType" href="http://www.productontology.org/id/Compact_Disk"/> >> >> cannot be considered a substitute for markup of the display. >> > > Again I'm not seeing your point - are you trying to say that it is only valid to use text on display as property values? > > If you are, how does this, where the data asserting it is an Audiobook is embedded in an attribute, fit in with that?: > > <div itemscope itemtype="http://schema.org/Audiobook"> > <span itemprop="name">Dune<span> > Format: Audiobook <br/> > > > >> Oddly enough, I am not finding examples where the carrier is marked up *at all* - not even in the movie or recorded music schemas. > > > That does not surprise me - the rest of the world is less inclined to categorise, then group those categories, of things as librarians do. > > A tall ginger bloke is not often referred to as a man of height type tall and hair colour red. > >> The Book schema uses this extension format, but with schema.org-defined terms: >> >> <link itemprop="bookFormat" href="http://schema.org/Paperback">Mass Market Paperback > > Yes, thats what is described as an internal, to the vocabulary, enumeration. >> >> Which seems a bit odd to me, but I can understand that they didn't want to create a class for each of the book product types. > > > Exactly why they encourage external enumerations for sets of externally managed values, because Schema would not be able to effectively manage them. > > Product Ontology, for one is following this encouragement, as I believe should we. > > We after all are not expecting Schema to manage authoratitve lists subjects, names, etc - so why think it for format types? > >> (Although schema has numerous classes that add no new properties.) >> >> In any case, I think we need to create examples both with and without the extensions to make sure that our proposals work either way. > > > > I'm all for providing examples of several ways of doing things. But I get the feeling that you believe that some are more right than others, or is that just a matter of personal preference? > > >> >> >> kc >> >> >> >>> >>> ~Richard. >>> >>>> >>>> This is analogous to: >>>> >>>> <span itemprop="creator">John Smith</span> >>>> >>>> There may be something better to call it than "abridged" - but I >>>> couldn't think of anything at the time. I am in touch now with some >>>> audiobook publishers so I can ask them these questions. This information >>>> should not be in a general note, though, because it has particular >>>> significance for the sales of audiobooks. I'll ask my contacts for >>>> better terminology. >>>> >>>> kc >>>> >>>> >>>> On 2/23/13 10:10 AM, Richard Wallis wrote: >>>>> I read the abridged property as having a Boolean intent - ³abridged² or >>>>> ³unabridged² - I was going to suggest ³yes²/²no² or true/false as more >>>>> appropriate ranges for such a property. >>>>> >>>>> Would not commonEndeavour not be a better way to link an abridged >>>>> AudioBook and the Book it is an abridgement of? >>>>> >>>>> ~Richard. >>>>> >>>>> >>>>> On 23/02/2013 16:30, "Young,Jeff (OR)" <jyoung@oclc.org> wrote: >>>>> >>>>> Karen has also proposed an abridged property with a range of Text. >>>>> It might be nice if the property was tweaked to have a domain and >>>>> range of schema:Book so the link between the two could be followed. >>>>> >>>>> Jeff >>>>> >>>>> Sent from my iPad >>>>> >>>>> On Feb 23, 2013, at 4:31 AM, "Richard Wallis" >>>>> <richard.wallis@oclc.org> wrote: >>>>> >>>>> Updated Example to reflect proposed Audiobook type Hi, >>>>> >>>>> Following Karen posting a proposed Audiobook Type, I have >>>>> updated the example in the Example Library to reflect it: >>>>> <http://www.w3.org/community/schemabibex/wiki/Examples/mylib/A8> >>>>> >>>>> ~Richard. >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net http://kcoyle.net >> ph: 1-510-540-7596 >> m: 1-510-435-8234 >> skype: kcoylenet >> >> -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Received on Thursday, 28 February 2013 16:26:35 UTC