New LinkRole type to support HTML attributes when data provided in JSON-LD #1045
I added these in pull request #1047.
For an EntryPoint which resolves to a resource/application available in multiple languages:
<script type="application/ld+json">
{
"@context": "http://schema.org/",
"@type": "Restaurant",
"potentialAction": {
"@type": "ReserveAction",
"target": [
"http://www.example.com/Reserve",
{
"@type": "LinkRole",
"target": "http://www.example.com/Reserve-JP",
"inLanguage": "jp",
"linkRelationship": "alternate"
}
]
}
}
</script>
For an article available in AMP HTML on mobile:
<script type="application/ld+json">
{
"@context": "http://schema.org/",
"@type": "Article",
"url": [
"http://www.example.com/article",
{
"@type": "LinkRole",
"url": "http://www.example.com/article-amp",
"linkRelationship": "amphtml"
}
]
}
</script>
The solution discussed here seems very ad hoc as there seems to be a more general need to say that links/entities/endpoints are "the same" while being specific to a specific language/country.
A few things I do not understand wrt linkRelationship in the examples:
- how to we know which Things are in the same link-relationship?
- what are the kinds of
linkRelationshipone can use? Can't those be URIs?
Other remarks:
- in #561, you used
inLanguageon aEntryPoint: what was wrong with that approach? - in Question on expressing translations of terms , several of us discussed about extending
schema:sameAsto things that are not webpages, which I believe that would apply quite well here as well
The kinds of linkRelationships are the same as supported in the "rel" attribute for the HTML tag. I hesitate to enumerate as there is a difference between the HTML5 documentation and how sites are marked up today. For example, "canonical" is supported by most (all?) modern browsers, but is not listed in the W3C docs.
I was going with text because that is what HTML uses. The idea was to use the same string one would use if the document were in HTML.
Initially, I see "alternate" and "amphtml" the most useful.
in #561, you used inLanguage on a EntryPoint: what was wrong with that approach?
We would need to update everything that expects URL to also expect EntryPoint. This seemed less weighty as Roles can already be used anywhere.
in Question on expressing translations of terms , several of us discussed about extending schema:sameAs to things that are not webpages, which I believe that would apply quite well here as well
I don't think I understand. How would that apply?
I hesitate to enumerate as there is a difference between the HTML5 documentation and how sites are marked up today. For example, "canonical" is supported by most (all?) modern browsers, but is not listed in the W3C docs.
In HTML5, only link types defined in the spec or registered in the Microformats wiki (http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions) can be used. On this page in the Microformats wiki, the link types amphtml and canonical are (currently) registered.
So the definition of the linkRelationship property could refer to http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions (if there is value in allowing/expecting the same link types that are allowed in HTML5).
So the definition of the linkRelationship property could refer to http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions (if there is value in allowing/expecting the same link types that are allowed in HTML5).
That makes sense. My point was that schema.org should not be defining these terms.
Thinking about this more, the AMP example would probably look like:
<script type="application/ld+json">
{
"@context": "http://schema.org/",
"@type": "Article",
"url": [
{
"@type": "LinkRole",
"url": "http://www.example.com/article",
"linkRelationship": "canonical"
},
{
"@type": "LinkRole",
"url": "http://www.example.com/article-amp",
"linkRelationship": "amphtml"
}
]
}
</script>
I've taken the current proposal manually from @vholland 's pull request and added it to the development version of the pending extension for review:
HTML's has a number of attributes for expressing language and how one URL relates to another. Unfortunately, JSON-LD has no such mechanism, so data in a feed cannot express things like "the endpoint is in Japanese" or "the endpoint is an alternate link".
We have touched on this idea in issue #561. A clearer, more extensible mechanism would be to add LinkRole:
A LinkRole is a Role that represents a Web link e.g. as expressed via the 'url' property. Its linkRelationship property can indicate URL-based and plain textual link types e.g. those in IANA
link registry or others such as 'amphtml'. This structure provides a placeholder where details from HTML's element can be represented outside of HTML, e.g. in JSON-LD feeds.
Itt would have two properties:
inLanguage: The language of the resource. (This property already exists. We would be extending the domain.)
linkRelationship: Indicates the relationship type of a Web link.