RE: Content-Carrier Proposal

The problem with the Metadata Registry URIs is that they identify skos:Concepts, not owl:Classes. That's why productontology.org had to coin new URIs rather than use Wikipedia/DBpedia URIs directly:

http://www.productontology.org/#faq1

If the Metadata Registry decided to follow suit, I would recommend switching from numeric URIs to transparent URIs. I realize the numeric forms are more language-neutral, but they are also a significant barrier to human convenience.

Jeff

> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Monday, February 04, 2013 9:29 AM
> To: public-schemabibex@w3.org
> Subject: Re: Content-Carrier Proposal
> 
> 
> 
> On 2/4/13 1:46 AM, Richard Wallis wrote:
> 
> > The approach of applying multiple types, proposed here, allows for a
> > thing to be of many types at the same time - a book, an audio book,
> > and a CD. This enables, with the benefit of initiatives such as
> > productontology.org, most types to be described leaving the option of
> > choosing which of the multiple types is the main focus to the
> consumer.
> 
> 
> Richard, I think that productontology.org can be ONE source of URIs,
> but definitely not the only one. Library data already has definitions
> of content and carrier (with URIs) [1], and publishers have their own
> in ONIX. In fact, I just looked at the wikipedia page for "audiobook"
> and it would include things that libraries consider distinct (spoken
> recording vs. audiobook). So each community will have its own
> definitions and they may be similar but have their own distinctions.
> 
> Within a community of practice it may be desirable to include the URI
> for the nearest productontology.org "thing" but that would be a
> community decision.
> 
> Also, I have to say that wikipedia mixes up content and carrier
> something terrible. Here is its definition of "book"
> 
> "A book is a set of written, printed, illustrated, or blank sheets,
> made of ink, paper, parchment, or other materials, usually fastened
> together to hinge at one side."
> 
> It may be good for non-creative products (printers and hard drives and
> such) but for creative works it is quite possible that libraries and
> publishers have done a better job of defining those things.
> 
> kc
> 
> [1] 336 - Content Type
> http://metadataregistry.org/concept/list/vocabulary_id/45.html
> 337 - Media Type
> http://metadataregistry.org/concept/list/vocabulary_id/37.html
> 338 - Carrier Type
> http://metadataregistry.org/concept/list/vocabulary_id/46.html
> >
> > Additional type was not in the original Schema spec, being introduced
> > a year later to add to microdata an ability, that comes by default
> > with RDFa, to replicate a real world need for multiple types.
> Because
> > of this we have a legacy of individual solutions, such as
> MediaObject,
> > which will cause some initial confusion as this more general approach
> > gets adopted.
> >
> > ~Richard.
> >
> > On 03/02/2013 23:57, "Niklas Lindström" <lindstream@gmail.com> wrote:
> >
> >     But I figure that the focus here is to find some minimal
> >     indication of this distinction via some properties on the same
> >     (overloaded) resource to start with. That should be usable too.
> >
> >     .. I may have made my own mess of conflations here of course,
> e.g. by
> >     equating container and manifestation. But I trust you to set me
> >     straight. ;)
> >
> >     Cheers,
> >     Niklas
> >
> >
> >     > On Feb 3, 2013, at 4:37 PM, Karen Coyle <kcoyle@kcoyle.net>
> wrote:
> >     >
> >     >> The question is: what about other industries? Music? Movie
> publishers? Software? Games? Groceries? I'm trying to think as broadly
> as possible.
> >     >>
> >     >> kc
> >     >>
> >     >> On 2/3/13 12:41 PM, Laura Dawson wrote:
> >     >>> Outside the library world, we refer to it as "content" and
> "container" -
> >     >>> so I don't think it's too far off.
> >     >>>
> >     >>> On 2/3/13 3:30 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
> >     >>>
> >     >>>> Richard,
> >     >>>>
> >     >>>> Thanks for starting this. My first comment is that we need
> some good
> >     >>>> definitions of "content" and "carrier." It's fairly common
> terminology
> >     >>>> in the library world but not beyond.
> >     >>>>
> >     >>>> My second is that this links to a more general discussion I
> have been
> >     >>>> thinking of starting on the general vocab list, which is
> about
> >     >>>> "re-usable bits and facets." The content and carrier
> concepts are almost
> >     >>>> universals and I can imagine "carrier" becoming a re-usable
> facet
> >     >>>> available to any schemas that fine it useful. (Ditto things
> like
> >     >>>> "location"). The library "content & carrier" could become a
> focus for
> >     >>>> talking about how truly non-specific these concepts are and
> why the
> >     >>>> creation of freely available facets could aid in metadata
> development.
> >     >>>>
> >     >>>> kc
> >     >>>>
> >     >>>> On 2/2/13 1:04 PM, Richard Wallis wrote:
> >     >>>>> Hi all,
> >     >>>>>
> >     >>>>> I have just added a Content-Carrier proposal to the Wiki.
> >     >>>>>
> >     >>>>> It does not propose extension of the vocabulary as such,
> but I have
> >     >>>>> linked it from the Vocabulary Proposals page
> >     >>>>>
> <http://www.w3.org/community/schemabibex/wiki/Vocabulary_Proposals> as
> >     >>>>> it is a proposal as to a recommended way to apply the
> current vocabulary
> >     >>>>> to address an issue that concerns this group.
> >     >>>>>
> >     >>>>>
> >     >>>>> ~Richard.
> >     >>>>
> >     >>>> --
> >     >>>> Karen Coyle
> >     >>>>kcoyle@kcoyle.net http://kcoyle.net
> >     >>>> ph: 1-510-540-7596
> >     >>>> m: 1-510-435-8234
> >     >>>> skype: kcoylenet
> >     >>
> >     >> --
> >     >> Karen Coyle
> >     >>kcoyle@kcoyle.net http://kcoyle.net
> >     >> ph: 1-510-540-7596
> >     >> m: 1-510-435-8234
> >     >> skype: kcoylenet
> >     >>
> >     >
> >
> >
> >
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>

Received on Monday, 4 February 2013 19:20:41 UTC