W3C home > Mailing lists > Public > public-vocabs@w3.org > December 2011

Re: [Feedback on schema.org] why is the expected type for "image" not an "ImageObject"?

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Tue, 20 Dec 2011 21:05:57 +0100
Cc: François Daoust <francois@joshfire.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
Message-Id: <34F9C7E0-5C40-4ABA-8D1D-5F2A3AC9AA82@ebusiness-unibw.org>
To: Alexander Shubin <ajax@yandex-team.ru>
I think the best would be to say that the range for the respective properties is the union of URL and ImageObject.

On Dec 16, 2011, at 4:20 PM, Alexander Shubin wrote:

> Hi Francois, Martin, 
> 
> I agree with Martin about keeping Thing as simple as possible. But 'thumbnail' and 'thumbnailUrl' is another issue so I raised it in our tracker (https://www.w3.org/2011/webschema/track/issues/8). 
> 
> About fallback mechanism. I think you may use it every time you want to keep you markup simple :)
> 
> ----
> Best Regards,
> Alex
> Yandex.com
> 
> 
> -----Original Message-----
> From: fdaoust@gmail.com [mailto:fdaoust@gmail.com] On Behalf Of Francois Daoust
> Sent: Wednesday, December 14, 2011 11:51 AM
> To: Martin Hepp
> Cc: public-vocabs@w3.org
> Subject: Re: [Feedback on schema.org] why is the expected type for "image" not an "ImageObject"?
> 
> Thanks for the response Martin,
> 
> Wouldn't the fallback mechanism that allows to use a URL regardless of the expected type solve the inconsistency and still allow both simple and more complete usage?
> 
> I agree the more complete usage with an ImageObject is overkill in most cases but it would still be nice to be able to do it, e.g. to credit the image of a Thing or a CreativeWork to its author directly in the markup. As things stand, it does not sound possible.
> 
> Or is this fallback mechanism more a hack only meant to be used in exceptional cases?
> 
> Francois.
> 
> 2011/12/12 Martin Hepp <martin.hepp@ebusiness-unibw.org>:
>> I think the reason for defining the range for the image property as "URL" is that everything else is overly complex and hard to understand for Webmasters.
>> You don't want to bother Webmasters with modeling that a certain URL is an ImageObject when they use the image property.
>> 
>> I think the current modeling is straightforward for the simple cases:
>> 
>> <div itemscope itemtype="http://schema.org/Product">
>>  <span itemprop="name">Kenmore White 17" Microwave</span>
>>  <img itemprop="image" src="kenmore-microwave-17in.jpg" alt='Kenmore 
>> 17" Microwave' />
>>  ...
>> </div>
>> 
>> With ImageObject, it would have to be
>> 
>> <div itemscope itemtype="http://schema.org/Product">
>>  <span itemprop="name">Kenmore White 17" Microwave</span>
>>  <span itemprop="image" itemscope itemtype="schema.org/ImageObject">
>>      <img itemprop="contentURL" src="kenmore-microwave-17in.jpg" 
>> alt='Kenmore 17" Microwave' />
>>  <span>
>>  ...
>> </div>
>> 
>> which adds quite a lot of indirection.
>> 
>> When modeling images explicitly, e.g. for news articles etc., the second approach may be appropriate, but for simply attaching the URL of an image to a Thing, I think it would be overkill to have a "image" property linking to an ImageObject linking to the URI via a contentULR property.
>> 
>> I agree that there is a bit of inconsistency, though.
>> 
>> Best
>> 
>> Martin Hepp
>> 
>> 
>> 
>> 
>> 
>> 
>> On Dec 12, 2011, at 11:29 AM, François Daoust wrote:
>> 
>>> Hi,
>>> 
>>> I have been playing a bit with the hierarchy defined in schema.org.
>>> Great schema! I have the following related couple of comments.
>>> 
>>> A Thing [1] has four properties. One of them is "image". The expected 
>>> type for this property is a URL. I do not understand why the expected 
>>> type is not ImageObject [2]. Other parts of the schema that reference 
>>> an image (or a media object) expect an ImageObject. For instance:
>>> - a CreativeWork [3] has an "audio" property that expects an 
>>> AudioObject, a "video" property that expects a VideoObject and an 
>>> "encodings" property that expects a MediaObject.
>>> - a WebPage [4] has a "primaryImageOfPage" property that expects an ImageObject.
>>> - a Place [5] has a "photos" property that expects an ImageObject (or 
>>> a Photograph).
>>> - the "thumbnail" property of an ImageObject expects an ImageObject as well.
>>> 
>>> I would guess that the main reason to have a URL for the "image"
>>> property is to stick to a "simple" Thing. But that does not look 
>>> consistent with the rest of the schema. Is there a good reason not to 
>>> expect an ImageObject?
>>> 
>>> The documentation mentions that URLs may be used in any case for 
>>> property values no matter what the expected type might be [6].
>>> Couldn't this fallback mechanism simply be used for Web pages that 
>>> simply want to mark an image without going into details about its 
>>> author and other metadata?
>>> 
>>> The second related comment is on "thumbnail" and "thumbnailUrl". Here 
>>> the schema does differentiate between URLs and ImageObject. A 
>>> CreativeWork defines a "thumbnailUrl" property that expects a URL. 
>>> The "thumbnail" property that expects an ImageObject is only defined 
>>> in ImageObject.
>>> 
>>> In short, I wonder whether the schema could be updated:
>>> 1. to expect an "ImageObject" for the "image" property (or to define 
>>> an additional property for that purpose) 2. to replace "thumbnailUrl" 
>>> with "thumbnail" (or to add a "thumbnail"
>>> property whenever "thumbnailUrl" is defined)
>>> 
>>> Did I miss something obvious?
>>> 
>>> Thanks,
>>> Francois Daoust.
>>> 
>>> [1] http://schema.org/Thing
>>> [2] http://schema.org/ImageObject
>>> [3] http://schema.org/CreativeWork
>>> [4] http://schema.org/WebPage
>>> [5] http://schema.org/Place
>>> [6] http://schema.org/docs/gs.html#schemaorg_expected
>>> 
>>> 
>> 
> 
Received on Tuesday, 20 December 2011 20:06:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 06:48:58 GMT