- From: Laura Dawson <ljndawson@gmail.com>
- Date: Wed, 13 Feb 2013 09:16:33 -0500
- To: <kcoyle@kcoyle.net>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
ONIX has had to solve many of these problems simply because there's money riding on accurate description of things. On 2/13/13 9:14 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >Yes, I think we should look at ONIX -- also because ONIX records should >be considered "in scope" for bibliographic microdata. In this case, "CD" >is part of the product description. > >kc > >On 2/13/13 7:57 AM, Laura Dawson wrote: >> 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_B >>oo >> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >> >> >> > >-- >Karen Coyle >kcoyle@kcoyle.net http://kcoyle.net >ph: 1-510-540-7596 >m: 1-510-435-8234 >skype: kcoylenet >
Received on Wednesday, 13 February 2013 14:17:07 UTC