isBasedOn definition

[unor]

Current definition for isBasedOn:

A resource that was used in the creation of this resource. This term can be repeated for multiple sources. For example, http://example.com/great-multiplication-intro.html.

I don’t understand what the last sentence (with the example URL) is supposed to mean (just to show how a URL value is supposed to look like?). And the second sentence doesn’t seem to be necessary, as this is the case for every property.

So I think the definition could just be:

A resource that was used in the creation of this resource.

+ examples that show the case of having one resource and the case of having multiple resources.

Opinions?

[thadguidry]

@unor Yeap examples help. PR is welcome !

[danbri]

Fair question @unor. Looking back via archive.org, it seems this definition has been the same since 2013 at least, https://web.archive.org/web/20130725184445/http://schema.org/isBasedOnUrl (it was 'isBasedOnUrl' previously).

I suggest just

A resource that was used in the creation of this resource.

...would be an improvement. Most properties are repeatable.

[philbarker]

Yep, isBasedOnUrl came from LRMI. It could be improved.
If I use photoshop to create a resource, that resource is not based on photoshop in sense meant by isBasedOn. How about: "a work from which this resource is derived" or "a work of which this resource is a modifcation"

[stuartasutton]

+1 to Phil's definition change suggestions with one possible wrinkle: "A work from which this work is derived or of which it is a modification or adaption."

[HughP]

In the LRMI context the name is clear that the value is expected to be a URL. However, if this value changes on Schema.org are we saying that we are also generalizing the expected value types?

[philbarker]

@HughP the expected range has already been expanded to be CreativeWork, Product and Url

[HughP]

Why does it not make sense to have two values:

• isBasedOn
• isBasedOnUrl

If we are going from more specific to more general, then any data which is already adherent to the more specific case will also adhere to the more general case, however by adding the more general term, and not deprecating the older, more specific term it seems that data marked up in this way will still continue to be valid, not requiring any changes on the part of data describers/standard users.
Not all works have a URL so The general case seems like it would be required for non-linkable items. Does it make sense in this context to separate out the URL field as a separate data thing?

[philbarker]

@HughP that change (from isBasedOnUrl to isBasedOn) was made in schema.org quite a long time ago. It follows a common schema.org pattern of allowing either a URL (URI, IRI) to identify the thing or an embedded description of the thing. In the case of an embedded description of the thing, that description can include the the URL as an identifier. In other words, if you want to explicitly provide a URL then you don't need the separate property:

{
 "@context": "http://schema.org/",
 "@type": "CreativeWork",
 "name": "A derivative",
 "isBasedOn": {
   "@type": "CreativeWork",
   "name": "An orginal",
   "url": "https://example.org/original"
 } 
}