Use of URL in a recipe

[ffes]

I recently utilized https://schema.org/Recipe to create an epub and (internal) website of all our favorite recipes from a collection of local files.

Now I run into an issue with the image property. .

In the example on https://schema.org/Recipe there is a line in the JSON that says: "image": "bananabread.jpg"

And on https://schema.org/ImageObject there is a similar example: "contentUrl": "mexico-beach.jpg"

But these values are not recognized when I parse this with SchemaSerializer.DeserializeObject<Recipe>("JSON");.

All the other properties in the JSON work as expected. Only the image property is not recognized.
I played a bit with it. When I add file:/// in front to it, it is recognized (obviously), but that is not what I need. I want to enter a relative filename that I can use to generate my HTML (used on the webpage). Both the examples suggests that those values are allowed.

Not sure if it is an implementation in Schema.NET, or that I am I doing something wrong.

[Turnerj]

Hey @ffes - looks like it is an implementation detail of Schema.NET.

In the ValuesJsonConverter, we are currently parsing URLs as absolute URLs which is likely tripping up what you've got.

That said, it doesn't seem that it is a requirement of schema.org to parse URLs that way. I'll need to investigate a little more but if I'm correct, it should be a fairly easy fix.

[Turnerj]

I'm unsure if that is the best solution.

On one hand, the Uri type seems a better fit for defining any type of URL (relative or absolute) so switching to UriKind.RelativeOrAbsolute would seem like the best option. Using string as a secondary type to store a URL, in my opinion, undermines the actual value (a relative URL is still a URL so why don't we make it a Uri). Some properties already have both types (string as schema.org Text and Uri as schema.org URL) so by using string to store a relative URL, we are saying that it could be text or a relative URL in those cases.

On the other hand, a relative URL can be practically anything. We attempt to convert by type from right-to-left in the generic arguments. For a property like identifier, that already has the types Uri, string and IPropertyValue (processed in that order). If we parse relative URLs as Uri, there will rarely/never be a value of string parsed as all will be thought of as relative URLs (thus everything becomes a Uri).

I'm not sure how well I explained it but it is kinda like both options have drawbacks. The former being a consistency thing, the latter being consistency thing with a splash of confusion.

No doubt, either solution will solve @ffes issue but both add oddities that, at minimum, would need to be well explained to those consuming Schema.NET.

[Turnerj]

For what it is worth, Google doesn't seem to support relative URLs consistently (eg. https://stackoverflow.com/questions/38434422/semantics-of-relative-urls-in-schema-org-breadcrumbs-in-json-ld). Some had success, some had errors. While whether Google supports it or not isn't really our problem, that it seems somewhat undocumented kinda makes me think the idea is that URLs are meant to be absolute as no ambiguity would exist (though that would obviously not help @ffes ).

[Turnerj]

Is there maybe a way we have a toggle to support relative URLs via Uri? I mean, we could have a static property exposed on ValuesJsonConverter that switches that logic? (Could look at an option value that is passed in but not sure how we otherwise get it to the converter)

[RehanSaeed]

Good point, I had totally forgot that Uri also does relative URL's.

[ffes]

I like the idea of an option to enable this. This way nothing breaks for existing users and when people (like me) want to use relative URLs they can do so.

[ffes]

I believe we'd simply need to add the string type to the list of acceptable types for a URL.

Sounds great to me.

From a consumer standpoint, relative URL's are not very developer friendly.

As always,,. It depends.

For my project absolute paths would be a nightmare. My source images are on Dropbox and they sit in another place on Linux and Windows (yep, I use them both). And the images are copied to the generated website and embedded in an epub. So relative paths (just filenames as in the examples I referred to) are ideal in my case.

But for other uses, relative paths could indeed be difficult to handle.