Re: Content-Carrier Proposal

Library data does have a short list of "types" that you can find as the 
categories of 007 fields:

007--MAP
007--ELECTRONIC RESOURCE
007--GLOBE
007--TACTILE MATERIAL
007--PROJECTED GRAPHIC
007--MICROFORM
007--NONPROJECTED GRAPHIC
007--MOTION PICTURE
007--KIT
007--NOTATED MUSIC
007--REMOTE-SENSING IMAGE
007--SOUND RECORDING
007--TEXT
007--VIDEORECORDING

Some may have to be renamed to be useful, and not all are creative works 
(e.g. remote-sensing image). I think this would get it down to 6-8 types.

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.html#att
>> 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:18:07 UTC