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: Mon, 12 Dec 2011 16:39:38 +0100
Cc: public-vocabs@w3.org
Message-Id: <55071BA1-EDD7-465D-8D97-C88CD106A34A@ebusiness-unibw.org>
To: François Daoust <francois@joshfire.com>
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' />

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

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.


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 Monday, 12 December 2011 15:40:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:21 UTC