Re: Content-Carrier Proposal

As Laura suggests, ONIX does to some degree separate out the carrier and content descriptions. But I wouldn't claim the one is hermetically sealed off from the other.

The carrier information is in ONIX properties ProductForm, ProductFormDetail and -- to some extent -- in ProductFormFeature. Information about the content starts in PrimaryContentType and ProductContentType, and of course goes on to encompass much of the rest of the record. So an audiobook on CD would be recorded as ProductForm = 'AC' (that is, as a CD-Audio product), ProductFormDetail 'A101' (that is, it's proper 'Red Book' CD-Audio, not one of those data CDs that happens to contain a bunch of audio files, which would be coded as AE and A103 or A107 (for mp3 or AAC files). ProductContentType would be '01' (which is the notation for 'audiobook' as distinguished from other types of audio like music or a recording of a speech or lecture.

Note that the ONIX properties or data elements often carry codes rather than textual values -- in SKOS, these would be notations rather than labels -- in order to provide a measure of language-independence to an ONIX description.

For those looking at the ONIX codelists using the link Laura gave, list 150 would be the list to look at for ProductForm, and list 175 for ProductFormDetail. ProductFormFeature uses list 79 plus a range of other controlled vocabularies. ProductContentType uses list 81. The lists are reviewed regularly to add new entries that become necessary. The review process is highly pragmatic, dependent on the ways that the book supply chain needs to describe its products.

Graham





Graham Bell

EDItEUR

Tel: +44 20 7503 6418


The information contained in this e-mail is confidential and may be privileged. It is intended for the addressee only. If you are not the intended recipient, please inform the sender and delete this e-mail immediately. The contents of this e-mail must not be disclosed or copied without the sender's consent. We cannot accept any responsibility for viruses, so please scan all attachments. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the company.


EDItEUR Limited is a company limited by guarantee, registered in England no 2994705. Registered Office: United House, North Road, London N7 9DP, UK. Website: http://www.editeur.org



On 13 Feb 2013, at 13:57, Laura Dawson wrote:

In ONIX we use what are called "composites" - a couple of different codes
together that describe a product. So, for example, an audiobook on CD
would have a product form code of CD-Audio and a product form type of
Audiobook.

If that helps.

ONIX code lists are here, for reference:
http://www.editeur.org/files/ONIX%20for%20books%20-%20code%20lists/ONIX_Boo
kProduct_CodeLists_Issue_20.html

On 2/13/13 8:49 AM, "Richard Wallis" <richard.wallis@oclc.org> wrote:

I am not trying to identify what is content or what is carrier - I am
trying
to identify what the type(s) of thing I am describing.

It is a CD AND it is a CreativeWork.  It is not a Creative work of
sub-type
CD, or music of sub-type CD.

For some consuming our data CD [in their eyes] may be the primary type
they
are interested in.

I would not say it is a narrowing of type I would suggest that it is a
broadening of access.

A retailer request to identify all their CDs, and possibly facet them by
those that are also audiobooks, music, software, blank for writing, etc.
would require much effort if each industry implemented a domain specific
view such as you propose.


~Richard.

On 13/02/2013 13:36, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

I'm still unclear whether 'additionalType' is the place to describe the
carrier of the content. I read 'additionalType' as further refinement of
the schema.org class. It needs to have a "type of" relationship to the
class that it is additional to. "CD" is not a "type of" creative work or
"type of" music. We should be look at a property, IMO, not a narrowing
of type.

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.h
tml#a
tt
r-itemtype