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

Thad,

The lines you quoted from Godby's report are indicative of the fact that content and carrier types are not simple.

ONIX for Books and MARC21 both address this problem, but in different ways, hence the mapping between them is complex.

However, the fact that the data models used in libraries and the book supply chain are both rather complex confirms the notion that a description should be "as simple as possible but no simpler"...

If the use case is to look at mediaTypes for access perhaps it might be helpful to think about a combination of several terms?

Michael

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>