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

True. Having developed codelists for several taxonomies, I'm sympathetic to the issue. I think Jean's work is going to prove quite useful to what needs to be accomplished. Mappings are inherently imperfect bi-directionally, but the useful thing about them is that they frequently surface the need for new terms on both sides.

(That said, the US ONIX folks still can't come to consensus on what a "page count" is - which tells me that not only do we have to start somewhere, we also have to know where to stop. And that is the "LEVEL" issue you refer to below.)

On Sep 21, 2012, at 2:40 PM, Thad Guidry <thadguidry@gmail.com<mailto:thadguidry@gmail.com>> wrote:

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<mailto: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<mailto: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<mailto: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<mailto: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<http://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@<mailto:thadguidry@>gmail.com<http://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<http://www.editeur.org/14/Code-Lists/#code%20lists>
On Fri, Sep 21, 2012 at 8:46 AM, Dawson, Laura <Laura.Dawson@bowker.com<mailto: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<mailto: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<mailto: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<mailto: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<http://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<http://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<http://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<http://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<tel:908-219-0082>
917-770-6641<tel:917-770-6641>
laura.dawson@bowker.com<mailto:laura.dawson@bowker.com>






--
-Thad
http://www.freebase.com/view/en/thad_guidry

Laura Dawson
Product Manager, Identifiers
Bowker
908-219-0082<tel:908-219-0082>
917-770-6641<tel:917-770-6641>
laura.dawson@bowker.com<mailto:laura.dawson@bowker.com>






--
-Thad
http://www.freebase.com/view/en/thad_guidry

Laura Dawson
Product Manager, Identifiers
Bowker
908-219-0082<tel:908-219-0082>
917-770-6641<tel:917-770-6641>
laura.dawson@bowker.com<mailto: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<mailto:laura.dawson@bowker.com>