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

Michael,

I am actually thinking about it much further than that (or rather Higher
Level than that to keep things simple, which is really what we need to
start with).

I will try to model a basic framework over this weekend and post onto the
Wiki.  (One of my borrowed ideas is "Format Tradename" as one proposed
property for some as yet-to-be-named Type, since I think that mediaType
itself might be too unclear and we may need physicalMediaType along with
others.  Avid Inc. uses Format Tradename, within the broadcasting world for
example:
http://www.avid.com/static/resources/us/documents/Avid_Editing_Systems_Supported_Formats_Feb-2011.pdf
 )

The industries affected by this discussion are not just the ones that
everyone on this list thinks about everyday.  It affects a very wide scope
where technology has touched humans, which in this present day is just
about EVERYWHERE, not just Public Libraries & Semantic Web groups...
Teachers to Diary Farmers to Rap Producers...the long tail domains.

On Fri, Sep 21, 2012 at 3:22 PM, Michael Hopwood <michael@editeur.org>wrote:

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