RE: Content-Carrier Proposal

Reinhold

While the RDA/ONIX Framework was used to determine the RDA content and
carrier categories, only the "base" attributes were used; there are many
other attributes identified in the Framework which have RDA values in other
RDA elements. Also, it was recognized at the time the Framework was
developed that ONIX would not use the Framework in the same way.

The true strength of the Framework lies in our ability to map high-level
categories, from RDA, ONIX, the MARC 21 007 material categories that Karen
posted, and, yes, the ISBD categories, into a central hub so that the scale
issues of one-to-one vocabulary mappings are avoided. As a result of this
thread, I've been mapping the MARC 21 and ONIX categories to the Framework
attributes; I've identified some issues that might be discussed if/when the
RDA/ONIX Framework Group is resurrected.

Using the Framework hub, it is possible to interoperate content and carrier
categories to answer user-drive queries such as: what resources contain
audio content? What resources contain braille music? Etc.

It would, of course, be most effective if new categories use only Framework
content attributes, or only Framework carrier attributes, without mixing
them up - but some degree of interoperability is possible whatever the
category.

For example, Onix's "Blank pages" has, at least, the value "interactive" in
the Interactive attribute of content...

Cheers

Gordon


-----Original Message-----
From: Heuvelmann, Reinhold [mailto:R.Heuvelmann@dnb.de] 
Sent: 13 February 2013 13:21
To: public-schemabibex@w3.org
Subject: Re: Content-Carrier Proposal

Karen, I think my motivation is maybe not the most beneficial, but somehat
stemming from laziness, and definitely from the experience of frustration,
as I have invested some time in collecting hierarchies of resource types,
based on MARC, and RDA, and ONIX, and some other approaches.  And each one
is doing it differently, sometimes only slightly, sometimes totally.

I still think that the RDA/ONIX Framework for Resource Categorization has
its merits as a framework, we don't have anything better, and I do admire
the efforts.  But when I see that RDA on the one hand and ISBD Area 0 on the
other hand use the framework, and they combine the parts in a different way,
resulting in different categories, so that afterwards the ends have to be
brought together by mapping efforts -- this is not the best way.

Yes, the distinction between Content/Concept and Carrier/Thing is a valid
one (a possible criterion for me is "can you destroy it?"), but sometimes
the lines are blurry.  And there are other "dimensions", as mode of
issuance, or the way a librarian looks at a "thing".

In other words:  There doesn't seem to be a Dewey-style way for resource
categorization, which would be a top-level distinction, with a clean and
one-way hierarchy down to the single types.

Regarding schema . org, I think I'm only talking about the sub-classes of
CreativeWork, as in the full Type Hierarchy.  I'm fine with the expected
types, and the additionalTypes as well.

Enough said about my emotions  :-)

Thank you ,

Reinhold


-----Ursprüngliche Nachricht-----
Von: Karen Coyle [mailto:kcoyle@kcoyle.net]
Gesendet: Mittwoch, 13. Februar 2013 16:39
An: public-schemabibex@w3.org
Betreff: Re: Content-Carrier Proposal

Reinhold, are you referring to the additionalTypes? Or are you referring to
the sub-classes of CreativeWork? If the latter, schema.org seems to be all
over the place. If you look at the full list, there are lots of "types" that
have no additional data elements. I admit that I'm not sure what schema.org
intends, but that seems to be the practice: if you have a different "thing"
you create a new schema. I find it odd.

Anyway, maybe you could enlarge a bit on what you see as the better
solution?

kc

On 2/13/13 8:38 AM, Heuvelmann, Reinhold wrote:
> In the whole business of resource categorization, I sometimes lean toward
a flat solution.  So instead of building up hierarchies of broad
distinctions, with narrower subtypes, and even narrower sub-subtypes, etc.
-- why not have single types, with definitions as clear as possible, but
without too many implications or restrictions (which a different user or
community would resist)?
>
> And using these flat types is just assigning and adding whatever fits,
without having to think too much about parents, children, siblings, or
overlaps etc.
>
> My 2 ct.
>
> Reinhold
>

--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Wednesday, 13 February 2013 20:07:57 UTC