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

Yes, I am not saying that the information is not useful for a viewing user.

However to be visible to a user, even in a rich snippet, does not
necessarily mean it needs it's own property in a vocabulary - it 'could' be
just appended to a description for that to happen.  From my briefest of
views, Amazon seem to put '3 CD Set' or '6 Volume Box Set' into the title.

For us to recommend a property, we need to have a clear understanding as to
it's, structured data, benefits.

The analysis of displays you are doing is very valuable to identify what
Amazon/Audible show to users - building a set of candidates for 'potential'
vocabulary properties.

~Richard.

On 25/02/2013 18:57, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>

Received on Monday, 25 February 2013 18:12:14 UTC