- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 04 Feb 2013 13:01:03 -0800
- To: "Young,Jeff (OR)" <jyoung@oclc.org>
- CC: public-schemabibex@w3.org
The "transparent v. numeric" is a hard one. Have you looked at the URIs for some of the RDA properties? Just because it isn't a number doesn't mean it's transparent :-) http://rdvocab.info/Elements/layoutOfTactileTextManifestation http://rdvocab.info/Elements/noteonChangesinContentCharacteristicsExpression And, of course, sometimes the "name" of the element changes. So I like the technique (it probably has a name) of using an opaque ID but adding the label to the URI at the time of display, the way the Open Library does it, where these two URIs are equivalent, in terms of what they point to: http://openlibrary.org/works/OL118420W/Flatland http://openlibrary.org/works/OL118420W/ I'm not sure this is the "right" way to do this, but adding some display to the URI seems to be the best of both worlds -- a URI that doesn't change, but a human readable form that adds a kind of "preflabel". kc On 2/4/13 11:20 AM, Young,Jeff (OR) wrote: > 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 >> > > > -- 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 21:02:09 UTC