- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 28 Feb 2013 10:39:01 -0800
- To: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
Ah, it's itemscope missing that bombs the validation. I had removed both. Which shows that there are some basic requirements for "well-formedness." I assume that there will be an attempt to create "good" microdata based on the standard. No, there is no requirement that there be an "essential" type - and rarely does library data make such a distinction (that's why we have that gawdawful "kit"). I actually see the sub-types in schema.org as being human-facing -- helping people find the place in the schema where they are most likely to discover appropriate metadata properties, and giving them guidance. This is a much smaller list than the universe of Wikipedia, and I think that's a good thing. (I also am not thrilled by relying on Wikipedia's definitions or their division of the universe in all cases.) As every class EXCEPT the Product class creates sub-classes for different types, and as CreativeWork has been developed in this way, I still vote for setting up a small number of types. kc On 2/28/13 9:44 AM, Young,Jeff (OR) wrote: > Sorry, my example had some cruft in it. Here it is again: > > <div itemscope=""> > <span itemprop="http://schema.org/name">Griffin</span> > </div> > > The point is that itemtype isn't "essential". Furthermore there is no reason to assume that itemtype is the place where people should put the "essential" class and that the non-essential types belong in the "additionalType". We aren't even required to believe that things HAVE an essential type. > > http://en.wikipedia.org/wiki/Essentialism > > Jeff > >> -----Original Message----- >> From: Young,Jeff (OR) [mailto:jyoung@oclc.org] >> Sent: Thursday, February 28, 2013 12:35 PM >> To: kcoyle@kcoyle.net; public-schemabibex@w3.org >> Subject: RE: Extension syntax Was: Re: Updated Example >> >>> 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. >> >> I don't think this is true. Here is a Microdata fragment that doesn't >> have an itemtype that the Rich Snippet tool is able to parse without >> complaint: >> >> <div itemprop="http://schema.org/publisher" itemscope=""> >> <span itemprop="http://schema.org/name">Griffin</span> >> </div> >> >> If the itemtype isn't included, it should be safe to infer >> http://schema.org/Thing as the itemtype. >> >> This is inferable type the only "essential" that is needed. Beyond >> that, there is no reason to think itemtype and additionalType have any >> semantic differences at all. If an item has two types, it doesn't >> matter which type goes in itemtype and which one(s) go in >> additionalType. >> >> Jeff >> >>> >>> 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 >>> > -- 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 18:39:31 UTC