- From: Laura Dawson <ljndawson@gmail.com>
- Date: Wed, 13 Feb 2013 08:57:04 -0500
- To: Richard Wallis <richard.wallis@oclc.org>, Karen Coyle <kcoyle@kcoyle.net>, <public-schemabibex@w3.org>
In ONIX we use what are called "composites" - a couple of different codes together that describe a product. So, for example, an audiobook on CD would have a product form code of CD-Audio and a product form type of Audiobook. If that helps. ONIX code lists are here, for reference: http://www.editeur.org/files/ONIX%20for%20books%20-%20code%20lists/ONIX_Boo kProduct_CodeLists_Issue_20.html On 2/13/13 8:49 AM, "Richard Wallis" <richard.wallis@oclc.org> wrote: >I am not trying to identify what is content or what is carrier - I am >trying >to identify what the type(s) of thing I am describing. > >It is a CD AND it is a CreativeWork. It is not a Creative work of >sub-type >CD, or music of sub-type CD. > >For some consuming our data CD [in their eyes] may be the primary type >they >are interested in. > >I would not say it is a narrowing of type I would suggest that it is a >broadening of access. > >A retailer request to identify all their CDs, and possibly facet them by >those that are also audiobooks, music, software, blank for writing, etc. >would require much effort if each industry implemented a domain specific >view such as you propose. > > >~Richard. > >On 13/02/2013 13:36, "Karen Coyle" <kcoyle@kcoyle.net> wrote: > >> I'm still unclear whether 'additionalType' is the place to describe the >> carrier of the content. I read 'additionalType' as further refinement of >> the schema.org class. It needs to have a "type of" relationship to the >> class that it is additional to. "CD" is not a "type of" creative work or >> "type of" music. We should be look at a property, IMO, not a narrowing >> of type. >> >> kc >> >> On 2/13/13 7:16 AM, Richard Wallis wrote: >>> On 13/02/2013 12:12, "Ed Summers" <ehs@pobox.com> wrote: >>> >>>> On Wed, Feb 13, 2013 at 6:54 AM, Richard Wallis >>>><richard.wallis@oclc.org> >>>> wrote: >>>>> In principle I agree with you - it is a kludge of a solution and >>>>>Microdata >>>>> could be improved by the ability to support multiple type URIs. >>>> >>>> My reading of the HTML 5 Microdata spec is that multiple types are >>>>allowed: >>>> >>>> The itemtype attribute, if specified, must have a value that is an >>>> unordered set of unique space-separated tokens that are >>>> case-sensitive, each of which is a valid URL that is an absolute >>>> URL, and all of which are defined to use the same vocabulary. >>>> The attribute's value must have at least one token. [1] >>> >>> It is the 'same vocabulary' bit that is the sticking point that >>>triggered >>> the 'addtionalType' work around. >>> >>>> >>>>> The original 'Library' extension proposal that accompanied the OCLC >>>>> WorldCat >>>>> linked data release last year, highlighted some of the carrier types >>>>> (catalogued by libraries which contribute records to WorldCat) that >>>>>were >>>>> missing from Schema. I am confident that that proposal will be >>>>>superseded >>>>> by recommendations from this group. >>>> >>>> If memory serves it highlighted all of the carrier types, or at least >>>> a lot more than I would have, which is something I will resist doing >>>> in schema.org. >>> >>> You and I both. >>> >>>> If OCLC wants to publish a comprehensive list of >>>> carrier types for use in microdata and RDFa that seems fine. >>> >>> An option open to everybody which I see nobody rushing to undertake. >>> >>> However, with the help of Product Ontology and the infrastructure of >>> Wikipedia, the community have made a really good start. >>> >>> >>>> But >>>> baking all of that into schema.org is not palatable for me, especially >>>> given the overlap with types that are already present. >>> >>> You and I both. >>> >>>> Is it too >>>> difficult for us to itemize which types are not present in schema.org >>>> that we need to have for expected use of bibliographic data? >>> >>> If it is not that difficult, some body, or individual, may see the >>>benefit >>> and take on the task, and the associated maintenance responsibility - >>>one of >>> the national libraries, LoC, NISO, BIBFRAME, OCLC, Code4Lib? >>> >>> Personally I would question if it would not be better to apply such >>>effort >>> to improving Wikipeadia's descriptions of these things and thus >>>increasing >>> product ontology's value to the world - not just libraries. >>> >>>> Can we >>>> take lossless transformation of MARC to schema.org off the table? >>> >>> Its not on my table - I am looking to provide a vocabulary to enable >>>the >>> description of anything (with a focus in this group on the >>>bibliographic >>> domain). Plus encourage the publishing/exposure of resource >>>identifiers >>> that can add value to such descriptions - what in the broadest sense we >>> [library folk] describe as authorities. >>> >>>> >>>> //Ed >>>> >>>> [1] >>>> >>>>http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.h >>>>tml#a >>>> tt >>>> r-itemtype >>>> >>> >>> >>> >>> > > >
Received on Wednesday, 13 February 2013 13:57:44 UTC