Re: Which properties to expose Was: Extension syntax Was: Re: Updated Example

Richard,

Extent is a good example as a necessary display but not necessarily 
something that needs a controlled vocabulary. Extent is an important bit 
of information for users as they make decisions about whether to obtain 
(in the FRBR sense), so if you think about rich snippet display, extent 
makes sense. Users want to know if they are looking at 7-volumes 
(Proust) or 32 pages (Proust in Cliff Notes). In terms of purchasing, a 
3-CD boxed set at $59.95 makes more sense than a single CD. Microdata 
markup is not only for machine processing, but for providing useful 
displays. This is why looking at the displays in Amazon or Audible or 
Barnes and Noble can give us a clue to what information might be useful 
in a rich snippet.

kc

On 2/25/13 9:46 AM, Richard Wallis wrote:
> I believe we [again] have diverged enough from the initial thread to warrant
> a fork ;-)
>
> On 25/02/2013 18:04, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>
>> I think it's not just being open about values -- I think this will also
>> inform what properties we define.
>> Extent is a good example -- if we
>> define only more specific properties ("duration" "number of pages") then
>> those undefined extent statements won't fit in any of the available
>> properties, and it makes even less sense to plot them into a random one.
>> So we need to think about what data people have and provide properties
>> for it, not just develop the properties that some think are "good" and
>> let people succeed or fail. I really recommend looking at "read data" to
>> inform our work.
>>
>> kc
>
> You raise a useful point here.
>
> If we decide to recommend 'extent' as a property, would it's content be
> useful to / relevant to / understandable by a structured [Microdata or RDFa]
> data consumer?  I'm not particularly picking on 'extent', this is a question
> we should be asking ourselves about any proposed property.
>
> It would be easy to fall into the trap of considering that anything felt
> worthy enough to be entered into a Marc record should be reproduced in a
> Schema.org property on some Type or other.
>
> Our role is not to attempt to remake Schema in Marc's/ONIX's image.  It is
> to use Schema [with hopefully as little extension as possible] to usefully
> represent resources from the bibliographic domain.
>
> I think the word useful is important.
>
> In the case of 'extent', I am not sure what a consumer (such as Google)
> would do differently if it found it's content in a general property such as
> 'description' instead of a specific 'extent' property.  As you say yourself,
> you would have to produce a parsing algorithm to make any [beyond human
> readable] sense of it.  As a data point, I can not see them, or anyone else
> making any use of it.
>
> Mapping from a detailed data format, such as Marc or ONIX, to a generic
> vocabulary such as Schema is by definition lossy.  As a community we need to
> accept that, whilst giving good justification (by our proposals) as to why
> it is [currently] too lossy.
>
> ~Richard.
>
> --
> Richard Wallis
> Technology Evangelist
> OCLC
>
>
>
>
>
>
>
>
>

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

Received on Monday, 25 February 2013 17:57:53 UTC