W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2012

Re: EXTERNAL: Re: Proposal for an additional term: mediaType

From: Thad Guidry <thadguidry@gmail.com>
Date: Fri, 21 Sep 2012 13:40:36 -0500
Message-ID: <CAChbWaMaPxbf86a4NX0snAE2XWWuq1SPeWVHs5sUDXfrVaFPBw@mail.gmail.com>
To: "Dawson, Laura" <Laura.Dawson@bowker.com>
Cc: Michael Hopwood <michael@editeur.org>, "Suliman, Suraiya H" <suraiya.h.suliman@lmco.com>, Dan Brickley <danbri@danbri.org>, "Evain, Jean-Pierre" <evain@ebu.ch>, Public Vocabs <public-vocabs@w3.org>, Greg Grossmeier <greg@creativecommons.org>, Thomas Baker <tom@tombaker.org>, Stuart Sutton <sasutton@dublincore.net>
Laura,

The basic problem at hand that we are trying to solve is exactly the
problem that Jean Godby at OCLC describes in that crosswalk research
paper:
http://www.oclc.org/resources/research/publications/library/2012/2012-04.pdf


that: " But a physical description is problematic because critical
information is coded in many elements in a MARC record, which necessitates
a complex mapping from ONIX and record-level validation of the MARC target
to ensure that the description is internally consistent. "

Physical descriptions
Format descriptions
 ..etc

There is no doubt that we need a MediaType.

The question is to what LEVEL and what PROPERTIES are needed to define a
MediaType that can be easily expanded on for future needs.
We all know that each new Hardware device that debuts each year, sometimes
compounds the problem of Physical descriptions, and Format descriptions.

Never ending change is never ending in this particular problem space.  But
we have to start somewhere.

On Fri, Sep 21, 2012 at 1:29 PM, Dawson, Laura <Laura.Dawson@bowker.com>wrote:

> I was thinking native to libraries - something as old as ONIX or maybe
> older. ONIX was developed for commercial use, originally - it's come a long
> way since 1999, but its purpose at first was for book sales. (I was on the
> original committee.)
>
> But if this has worked for libraries, so much the better. It simplifies
> things.
>
> On Sep 21, 2012, at 2:19 PM, Thad Guidry <thadguidry@gmail.com> wrote:
>
> Laura,
>
> The cross-walking for MARC21 and libraries is explained here:
> http://www.editeur.org/96/ONIX-and-MARC21/
>
> On Fri, Sep 21, 2012 at 12:42 PM, Dawson, Laura <Laura.Dawson@bowker.com>wrote:
>
>> I've been poking around, looking for library-oriented codelists for
>> formats, but so far no luck.
>>
>> On Sep 21, 2012, at 1:39 PM, Michael Hopwood <michael@editeur.org> wrote:
>>
>> And here, as HTML:
>> http://www.editeur.org/ONIX/book/codelists/current.html - relevant lists
>> are 150, 175, 176 and 76.****
>>
>> Yesterday I went to a workshop as part of www.linkedheritage.eu where we
>> experimented and discussed expressing them in SKOS…****
>>
>> This has also been covered in detail in the RDA/ONIX framework:
>> http://www.loc.gov/marc/marbi/2007/5chair10.pdf****
>>
>> *From:* Thad Guidry [mailto:thadguidry@gmail.com]
>> *Sent:* 21 September 2012 16:22
>> *To:* Dawson, Laura
>> *Cc:* Suliman, Suraiya H; Dan Brickley; Evain, Jean-Pierre; Public
>> Vocabs; Greg Grossmeier; Thomas Baker; Stuart Sutton
>> *Subject:* Re: EXTERNAL: Re: Proposal for an additional term: mediaType**
>> **
>> ** **
>> The Current ONIX codes are here:****
>> ** **
>>
>> http://www.editeur.org/14/Code-Lists/#code lists ****
>> On Fri, Sep 21, 2012 at 8:46 AM, Dawson, Laura <Laura.Dawson@bowker.com>
>> wrote:****
>> Check ONIX codelists as well. Some useful stuff in those.****
>> ** **
>> On Sep 21, 2012, at 9:41 AM, "Suliman, Suraiya H" <
>> suraiya.h.suliman@lmco.com> wrote:****
>>
>>
>> ****
>> The list I have contains the following values. Note that this is not a
>> complete list, just one from a particular publisher.
>>
>> Audio CD
>> Audiotape
>> Calculator
>> CD-I
>> CD-ROM
>> Diskette
>> Duplication Master
>> DVD/ Blu-ray
>> E-Mail
>> Electronic Slides
>> Field Trip
>> Filmstrip
>> Flash
>> Image
>> In-Person/Speaker
>> Interactive Whiteboard
>> Manipulative
>> MBL (Microcomputer Based)
>> Microfiche
>> Overhead
>> Pamphlet
>> PDF
>> Person-to-Person
>> Phonograph Record
>> Photo
>> Podcast
>> Printed
>> Radio
>> Robotics
>> Satellite
>> Slides
>> Television
>> Transparency
>> Video Conference
>> Videodisc
>> Webpage
>> Wiki
>>
>>
>> ________________________________________
>> From: Dan Brickley [danbri@danbri.org]
>> Sent: Friday, September 21, 2012 8:57 AM
>> To: Suliman, Suraiya H
>> Cc: Evain, Jean-Pierre; Public Vocabs; Greg Grossmeier; Thomas Baker;
>> Stuart Sutton
>> Subject: EXTERNAL: Re: Proposal for an additional term: mediaType
>>
>> On 21 September 2012 14:21, Suliman, Suraiya H
>> <suraiya.h.suliman@lmco.com> wrote:
>>
>> ****
>> Trying to revive this thread as those of us working on the LRMI tagger
>> see a need to capture "mediaType" information and would like to work
>> towards consensus on how to handle this in Schema.org<http://schema.org/>
>> .
>>
>> Given that DC and EBUCore (among others) have tried to address this issue
>> and have some proposed solutions, how can we accomodate format/medium in
>> schema.org? I think attributes "encoding" and "genre" ad dress things
>> covered by DC "type". There is still a need to for things like MIMEtype,
>> the physical medium,  container format etc. Can we start with the DC
>> "format" as the straw-man and see if this adequately covers "format" in
>> schema.org?****
>>
>>
>> Thanks for the nudge here.
>>
>> As previous discussion shows, various communities have all got some
>> partial coverage of this issue, and as we consider e.g. the Library
>> -oriented proposals from OCLC to improve our bibliographic vocabulary,
>> the same ("content vs carrier") distinctions will re-appear.
>>
>> Can we separate the question of 'which schema.org property to use'
>> from the question of the values? What would be super-useful right now,
>> is a list of those specific values. We'll need to split them into
>> fields/properties of course, but for now just seeing a big collection
>> of the values would be helpful... particularly those that occur in
>> educational datasets.  Generally with schema.org we try to 'surface'
>> existing content in more explicit form, rather than introduce new
>> representations, so anything you have from the LRMI community could
>> help guide us...
>>
>> cheers,
>>
>> Dan****
>> ** **
>> Laura Dawson****
>> Product Manager, Identifiers****
>> Bowker****
>> 908-219-0082****
>> 917-770-6641****
>> laura.dawson@bowker.com****
>>
>>
>> ** **
>>
>>
>> ****
>> ** **
>> --
>> -Thad
>> http://www.freebase.com/view/en/thad_guidry****
>>
>>
>>  Laura Dawson
>> Product Manager, Identifiers
>> Bowker
>> 908-219-0082
>> 917-770-6641
>> laura.dawson@bowker.com
>>
>>
>>
>>
>
>
> --
> -Thad
> http://www.freebase.com/view/en/thad_guidry
>
>
> Laura Dawson
> Product Manager, Identifiers
> Bowker
> 908-219-0082
> 917-770-6641
> laura.dawson@bowker.com
>
>
>
>


-- 
-Thad
http://www.freebase.com/view/en/thad_guidry
Received on Friday, 21 September 2012 18:41:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 18:41:04 GMT