thumbnailUrl and contentUrl are questionable

[VladimirAlexiev]

Consider these two props:

• thumbnail (ImageObject): Thumbnail image for an image or video.
• thumbnailUrl (URL): image relevant to the Thing

I think they basically mean the same, but the latter case points directly to the image, while the former case introduces an intermediate node ImageObject that points to the image using ImageObject.contentUrl, and can hold more info about the thumbnail (eg width, height, exifData)

Now consider:

• image (ImageObject or URL): An image of the item. This can be a URL or a fully described ImageObject.

That's just one property (better!) but it still entertains two different possible cases.

My question is what is the purpose of the intermediate node, and why can't I record extra props directly against the image URL, eg

<person> image <person/portrait.jpg>, thumbnail <person/portrait-thumb.jpg>.
<person/portrait.jpg> a ImageObject; width 1024; height 768; thumbnail <person/portrait-thumb.jpg>.
<person/portrait-thumb.jpg> a ImageObject; width 102; height 76.

The current guidelines suggest I should go something like this:

<person> image <person/portrait>, thumbnail <person/portrait-thumb>;
  thumbnailUrl <person/portrait-thumb.jpg>.
<person/portrait> a ImageObject; width 1024; height 768; thumbnail <person/portrait-thumb>;
  contentUrl <person/portrait.jpg>.
<person/portrait-thumb> a ImageObject; width 102; height 76;
  contentUrl <person/portrait-thumb.jpg>.

There is maybe one consideration: <person/portrait> could live on some "data" server whereas <person/portrait.jpg> could live on another "image" server. But there's no problem to host triples about some external resource on any data server.
Or someone may decide to use a blank node instead of<person/portrait>, but that begs the question, why not use <person/portrait.jpg> directly?

In #1781 @danbri writes "There is something special (and awkward) around our use of "URL". We have used it in schemas to hint that a property's values may be links rather than locally described entities".

Indeed: URL is no different from an RDF resource, and treating differently can just create confusions like the one above.

Suggestions:

• deprecate thumbnailUrl. (If not, you need to introduce imageUrl for symmetry)
• show examples of recording props directly against image URLs
• (I guess deprecating contentUrl would be quite disruptive, but some link to the above examples would be nice)

@rvguha and @RichardWallis, what do you think?

[vholland]

The range for image already includes both URL and ImageObject. Given that we have lots of naming inconsistencies, I don't see the benefit in adding imageUrl at this time.

I do not agree that we can do away with the intermediate node. In JSON-LD, there is no way to record the properties like height and width.

I could get behind deprecating thumbnailUrl, but there is a lot of markup out there using that property, so realistically any consumer will need to support the thumbnailUrl for some time. I do not think it is worth deprecating the property now unless we are doing some larger cleanup.

[rvguha]

+100 for what Vicki says. Yes, there is some cruft. But we have to weigh the cost of cleanup vs the benefit. guha

…

On Thu, Nov 2, 2017 at 10:08 AM, vholland ***@***.***> wrote: The range for image already includes both URL and ImageObject. Given that we have lots of naming inconsistencies, I don't see the benefit in adding imageUrl at this time. I do not agree that we can do away with the intermediate node. In JSON-LD, there is no way to record the properties like height and width. I could get behind deprecating thumbnailUrl, but there is a lot of markup out there using that property, so realistically any consumer will need to support the thumbnailUrl for some time. I do not think it is worth deprecating the property now unless we are doing some larger cleanup. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1788 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlCq_adpp6vBjrjlBuZMVMM3tFRHsDks5syfb_gaJpZM4QP2Df> .

[danbri]

I can see room for clarification but I can't see adding yet another cluster of options (imageUrl) adding to that clarity. Let's bookmark this as something that - as @vholland says - could be a piece of a larger cleanup/clarification for these kinds of pattern.

[danbri]

In terms of our own definitions I don't see anything wrong with the example,

<person/portrait.jpg> a ImageObject; width 1024; height 768; thumbnail <person/portrait-thumb.jpg>.
<person/portrait-thumb.jpg> a ImageObject; width 102; height 76.

In practice I'm not sure which products understand this 'thumbnail'-based idiom vs 'thumbnailUrl'.

BTW I've been looking into getting more stats released but as an interim aside at Google we're seeing approx 3x as many uses of 'thumbnailUrl' as for 'thumbnail' in terms of occurrences, and somewhat over 10x as many domains (assume some fuzzyness and handwaving on details but wanted to share some rough info).

[VladimirAlexiev]

@vholland Don't know where you saw that I'm proposing adding imageUrl. Then we'd also need audioUrl, videoUrl etc. This proposal is to deprecate thumbnailUrl.

I do not think it is worth deprecating the property now unless we are doing some larger cleanup

Do you mean other similar props exist? Can you list them?

In JSON-LD, there is no way to record the properties like height and width.

My simplified example "directly against the image URL" is valid Turtle, so of course it can be represented in JSONLD. And as @danbri says "I don't see anything wrong with the example".

I now also propose to deprecate contentUrl in favor of the simpler way (recording ImageObject attributes directly against an image URL). Deprecating doesn't make the existing data invalid, so it doesn't create undue hardships for providers.

[vholland]

@VladimirAlexiev

Do you mean other similar props exist? Can you list them?

Do you mean URLs or places where we are inconsistent in naming/usage patterns? For the latter, off the top of my head, we have never really resolved how to clean up names that differ by case only. (e.g. contactPoint and ContactPoint) There are different enumeration naming patterns based on various attempts to come up with a pattern that makes sense for the immediate use case but can be expanded for other use cases.

In JSON-LD, there is no way to record the properties like height and width.
My simplified example "directly against the image URL" is valid Turtle, so of course it can be represented in JSONLD. And as @danbri says "I don't see anything wrong with the example".

I don't understand. If we remove the intermediate ImageObject, there is no subject for the height and width properties.

I now also propose to deprecate contentUrl in favor of the simpler way (recording ImageObject attributes directly against an image URL). Deprecating doesn't make the existing data invalid, so it doesn't create undue hardships for providers.

contentUrl is a property of MediaObject. While the difference between contentUrl and embedUrl is for images is debatable, the distinction is important for other media like videos and music.

[VladimirAlexiev]

@vholland I mean inconsistent usage patterns? There's nothing wrong with having prop contactPoint and class ContactPoint. But it's wrong to have both thumbnail and thumbnailUrl, if you don't have the same duality for image, audio, video, etc.

If we remove the intermediate ImageObject...

See my first code block. <person/portrait-thumb.jpg> is both ImageObject, and the actual thumbnail URL. There's no need for an intermediate node.

While the difference between contentUrl and embedUrl is for images is debatable, the distinction is important for other media like videos and music

This justifies the need for embedUrl but not contentUrl.

I might be mistaken, but to me embedUrl is sort of similar to thumbnail

• images have main URL and may have thumbnail
  (actually there may be multiple sizes, eg see Yale Image Formats and Image Views examples but that's more a topic for IIIF)
• videos have main URL and may have embedUrl and thumbnail
  (actually why just one? Every key frame may have a thumbnail... but that's another topic)

[vholland]

@VladimirAlexiev "Wrong" is a strong word.

What is the issue we are trying to address? If it is consistency, I don't think it is worth addressing each inconsistency one at a time, but better to look at them holistically.

[rvguha]

I strongly agree with Vicki. Much of Schema.org is not about 'correct vs wrong' but about designing to maximize adoption and utility. guha

…

On Fri, Nov 3, 2017 at 9:31 AM, vholland ***@***.***> wrote: @VladimirAlexiev <https://github.com/vladimiralexiev> "Wrong" is a strong word. What is the issue we are trying to address? If it is consistency, I don't think it is worth addressing each inconsistency one at a time, but better to look at them holistically. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1788 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlCpCs_Ce-bMr-Zu-g3fTnvhevIfMRks5syz_agaJpZM4QP2Df> .

[danbri]

Agree that "wrong" is too strong, but it is reasonable to note that too many different patterns can cause usability problems for publishers.

[rvguha]

Yes, I don't think anyone disagrees that some cleanup is required. The point is that when we do so, we need to be super cognizant of the impact on the publisher and consumer communities on any changes we make. guha

…

On Fri, Nov 3, 2017 at 1:25 PM, Dan Brickley ***@***.***> wrote: Agree that "wrong" is too strong, but it is reasonable to note that too many different patterns can cause usability problems for publishers. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1788 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlCmGhHvDG2nIy17LuFseO6W9tt2Zeks5sy3apgaJpZM4QP2Df> .

[danbri]

Yup.

Basically we don't mind looking bad (inconsistent, crappy flat models etc.) so long as it doesn't make life harder for publishers.

It would be tempting to try to beautify and formalize and normalize a lot of things, except that it would make work for millions of sites. But our modelling and naming would be cleaner.

[VladimirAlexiev]

If it is consistency, I don't think it is worth addressing each inconsistency one at a time

@vholland as I asked above: what other inconsistencies do you have in mind? And if not one at a time, how would you propose to address them?

designing to maximize adoption and utility

I think that consistency is a very important quality supporting adoption and utility.
Having thumbnail and thumbnailUrl, without the same duality for image, audio, video, etc; is inconsistent.

Suggesting more complex RDF shapes than necessary also doesn't help adoption and utility.

[VladimirAlexiev]

@danbri > so long as it doesn't make life harder for publishers.

Let's analyze this. how would my two Turtle examples look in RDFA and in Microdata?(http://schema.org/thumbnailUrl and http://schema.org/thumbnail don't give examples)

If the more complex Turtle looks easier in RDFA then you'll win a point.

[LautaroLobo12]

So, I have my blog and I was looking if I should use image or thumbnailUrl for the cover image of my posts. Any suggestion? Couldn't find anything on the internet.

[WeaverStever]

@LautaroLobo12

You would use the markup tor type NewsArticle, type BlogPosting also works with the testing tool on the Google example. Note that you can provide multiple images with different aspect ratios.

https://developers.google.com/search/docs/data-types/article

[github-actions]

This issue is being tagged as Stale due to inactivity.