Re: Content-Carrier Proposal

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_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
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
>
>

-- 
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:14:36 UTC