- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 30 Sep 2013 12:24:50 -0700
- To: Dan Brickley <danbri@google.com>
- CC: "Wallis,Richard" <Richard.Wallis@oclc.org>, Guha <guha@google.com>, W3C Vocabularies <public-vocabs@w3.org>
On 9/30/13 11:24 AM, Dan Brickley wrote: > On 30 September 2013 19:15, Wallis,Richard <Richard.Wallis@oclc.org> wrote: >> Is this not why 'additionalType' was added to Thing? > > Yes: Microdata has trouble with the idea of describing an item using > multiple independently defined types: > > " Multiple types defined to use the same vocabulary can be given for a > single item by listing the URLs as a space-separated list in the > attribute' value. An item cannot be given two types if they do not use > the same vocabulary, however." -- > http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#typed-items > > Rather than trying to gradually turn Microdata into something that it > isn't (i.e. back into RDFa), the schema.org team decided instead to > add the additionalType property. I had understood the "additionalType" as mainly having a function of categorization -- this thing is both an apple and a fruit. Does the use of an additionalType that is a schema.org type provide access to all of the properties of the additionalType? kc At the time we noted "In RDFa syntax, > it is better to use the native RDFa syntax - the 'typeof' attribute - > for multiple types. Schema.org tools may have only weaker > understanding of extra types, in particular those defined > externally.". Despite that I've subsequently heard a few people argue > that it is nice to know which type is in some informal sense the > 'main' one, so you could even make a case to use additionalType more > widely. > > Dan > >> ~Richard >> >> On 30 Sep 2013, at 17:19, Guha <guha@google.com> wrote: >> >> From the perspective of the graph that is built (and hopefully, hence the >> applications of the data), there is no difference. >> >> The difference should only be in the DOM. >> >> guha >> >> >> On Mon, Sep 30, 2013 at 9:13 AM, Karen Coyle <kcoyle@kcoyle.net> wrote: >>> >>> Thanks, Guha, and pardon my "term dyslexia" re: micro/data/format. >>> >>> So for audiobooks, would we have: >>> >>> <div itemscope itemtype="http://schema.org/Audiobook >>> http://schema.org/Product"> >>> >>> And/or a nesting of itemtypes: >>> >>> <div itemscope itemtype="http://schema.org/Audiobook"> >>> [audiobook information here] >>> <div itemtype="http://schema.org/Product"> >>> [product information here] >>> >>> In other words, can you "step down" the itemtypes, with the audiobook >>> description first, then product information as a subordinate set of data? >>> >>> Is there a functional difference? >>> >>> kc >>> >>> >>> On 9/30/13 8:28 AM, Guha wrote: >>>> >>>> I don't believe microformats have the concept of explicit types. >>>> >>>> With microdata, rdfa and json-ld, yes, you can. >>>> >>>> guha >>>> >>>> >>>> On Mon, Sep 30, 2013 at 8:16 AM, Karen Coyle <kcoyle@kcoyle.net >>>> <mailto:kcoyle@kcoyle.net>> wrote: >>>> >>>> I believe there was a question about using multiple types in >>>> microformat markup which I can't find now, nor an answer. So in case >>>> I dreamed it all, I'll rephrase it here: can one use multiple types >>>> in a microformat markup, and could someone please provide a brief >>>> example? >>>> >>>> Thank you, >>>> kc >>>> >>>> >>>> On 9/26/13 5:46 AM, Vicki Tardif Holland wrote: >>>> >>>> >>>> On Thu, Sep 26, 2013 at 8:26 AM, Martin Hepp >>>> <martin.hepp@ebusiness-unibw.__org >>>> <mailto:martin.hepp@ebusiness-unibw.org> >>>> <mailto:martin.hepp@ebusiness-__unibw.org >>>> >>>> <mailto:martin.hepp@ebusiness-unibw.org>>> wrote: >>>> >>>> Now, we can take at least two approaches for handling this: >>>> >>>> 1. We can use multiple supertypes, i.e. materialize a >>>> multiple >>>> inheritance relation (e.g. make AudioBook a subtype of both >>>> CreativeWorks and Product) >>>> 2. We can encourage the use of multiple types at markup >>>> time. >>>> >>>> I strongly recommend option #2, because >>>> >>>> - it waives the need to define relevant combinations ex >>>> ante, >>>> - it avoids the irritating listing of properties that are >>>> not >>>> relevant for most use cases, and >>>> - it decouples the evolution of type combinations from the >>>> evolution >>>> of the schema.org <http://schema.org> <http://schema.org> >>>> >>>> specification. >>>> >>>> >>>> >>>> Decoupling the evolution of type combinations from the evolution >>>> of the >>>> specification is an important point. If we have to serve all of >>>> the uses >>>> of AudioBook (or any other type) in its specification, we are >>>> going to >>>> end up with a tangle of multiple inheritance and/or duplicate >>>> properties >>>> which authors will not understand how to use. >>>> >>>> - Vicki >>>> >>>> Vicki Tardif Holland | Ontologist |vtardif@google.com >>>> <mailto:vtardif@google.com> >>>> <mailto:vtardif@google.com <mailto:vtardif@google.com>> >>>> >>>> >>>> -- >>>> Karen Coyle >>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>> m: 1-510-435-8234 <tel:1-510-435-8234> >>>> skype: kcoylenet >>>> >>>> >>> >>> -- >>> Karen Coyle >>> kcoyle@kcoyle.net http://kcoyle.net >>> m: 1-510-435-8234 >>> skype: kcoylenet >>> >> >> > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Received on Monday, 30 September 2013 19:25:15 UTC