-
Notifications
You must be signed in to change notification settings - Fork 822
-
Notifications
You must be signed in to change notification settings - Fork 822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
thumbnailUrl and contentUrl are questionable #1788
Comments
The range for 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 I could get behind deprecating |
+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>
.
|
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. |
In terms of our own definitions I don't see anything wrong with the example,
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). |
@vholland Don't know where you saw that I'm proposing adding
Do you mean other similar props exist? Can you list them?
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 |
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.
I don't understand. If we remove the intermediate ImageObject, there is no subject for the
|
@vholland I mean inconsistent usage patterns? There's nothing wrong with having prop
See my first code block.
This justifies the need for I might be mistaken, but to me
|
@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. |
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>
.
|
Agree that "wrong" is too strong, but it is reasonable to note that too many different patterns can cause usability problems for publishers. |
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>
.
|
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. |
@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?
I think that consistency is a very important quality supporting adoption and utility. Suggesting more complex RDF shapes than necessary also doesn't help adoption and utility. |
@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. |
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. |
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 |
This issue is being tagged as Stale due to inactivity. |
Consider these two props:
thumbnail
(ImageObject
): Thumbnail image for an image or video.thumbnailUrl
(URL
): image relevant to the ThingI 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 usingImageObject.contentUrl
, and can hold more info about the thumbnail (egwidth, height, exifData
)Now consider:
image
(ImageObject
orURL
): 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
The current guidelines suggest I should go something like this:
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:
thumbnailUrl
. (If not, you need to introduceimageUrl
for symmetry)contentUrl
would be quite disruptive, but some link to the above examples would be nice)@rvguha and @RichardWallis, what do you think?
The text was updated successfully, but these errors were encountered: