Re: Content-Carrier Proposal

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

Received on Wednesday, 13 February 2013 13:50:04 UTC