MediaObject / embedUrl and contentUrl are confusing

[mfhepp]

I think that the descriptions for the following two properties are confusing:

contentUrl
Actual bytes of the media object, for example the image file or video file.
-> Maybe better as: The URL of the actual media object, e.g. the image or video file.

embedUrl
A URL pointing to a player for a specific video. In general, this is the information in the src element of an embed tag and should not be the same as the content of the loc tag.

What is meant with the loc tag? Neither nor

This should be explained in the examples.

Note: This issue is related to #416.

[Aaranged]

I would add to this list:

url
URL of the item.

For MediaObject neither the cited property descriptions nor the examples provide guidance under which circumstances "contentUrl" should be used rather than "url". What is the difference between the two?

[blikkie]

I presume loc refers to the loc tag of the sitemaps protocol: http://www.sitemaps.org/protocol.html

Also, isn't the url redundant for a MediaObject any MediaObject is a Thing?

[Aaranged]

Great catch with loc @blikkie. The reference to loc is indeed sitemap related. It comes directly from the Google Webmaster Tools Help page Creating a Video Sitemap, which reads:

A URL pointing to a player for a specific video. Usually this is the information in the src element of an tag and should not be the same as the content of the <loc> tag.

Because loc is not a schema.org property - and, indeed, except for this reference in relation to embedUrl isn't documented anywhere on schema.org - this should be removed from the cleaned up description for embedUrl (or explained in reference to sitemaps).

Re url I'm going to paste something on this issue from Dan Scott in a subsequent comment.

[Aaranged]

Dan Scott - @dbs - provided this in a post on the public-schemaorg mailing list, which I'm copying and pasting here because I think it adds clarity to these issues:

I'm willing to take a stab at an answer (and thus willing to be wrong!). It probably works better with VideoObject or AudioObject examples which are more likely to have embeddable players.

• url: is for a URL that offers additional info about the given MediaObject (example: https://archive.org/details/WhatIsLinkedDataAndWhatDoesItMeanForLibraries)
• contentUrl: is for URL that provides a directly retrievable instance of the MediaObject (example: https://archive.org/download/WhatIsLinkedDataAndWhatDoesItMeanForLibraries/2010.10.15Nla2010LinkedData.ogv
  )

... and to add in a suggested answer to Martin's related question around embedUrl:

• embedUrl: is for a URL that can be used to embed the media on a web page via a specific media player (example:
  http://archive.org/embed/WhatIsLinkedDataAndWhatDoesItMeanForLibraries -- often embedded in an iframe element like <iframe src="https://archive.org/embed/WhatIsLinkedDataAndWhatDoesItMeanForLibraries" width="640" height="480" frameborder="0" webkitallowfullscreen="true" mozallowfullscreen="true" allowfullscreen></iframe>). And of course this URL will often be used in the page referenced by schema:url about the VideoObject :)

So ultimately you could have a object with meaningfully distinct properties like:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "VideoObject",
  "contentUrl": "https://archive.org/download/WhatIsLinkedDataAndWhatDoesItMeanForLibraries/2010.10.15Nla2010LinkedData.ogv
",
  "embedUrl": "http://archive.org/embed/WhatIsLinkedDataAndWhatDoesItMeanForLibraries",
  "url": "https://archive.org/details/WhatIsLinkedDataAndWhatDoesItMeanForLibraries",
  "name": "What is Linked Data and What Does it Mean for Libraries?"
}
</script>

To summarize:

• I think all three properties have a reason to exist, if you look at them in context with one another
• The properties probably make much more sense if used with a more conventionally streamable example such as AudioObject or VideoObject
• We probably need to add more examples in this area, and ensure that we have some in which all of contentUrl, embedUrl, and url appear (and hang those examples off the properties, too) :)

[github-actions]

This issue is being tagged as Stale due to inactivity.