schemaorg
Using more than one mainEntitym
Hi! I have seen many web pages, and also articles, suggesting the usage of the "about" property more than once, indicating that the webpage is about more than 1 thing. ...But when we use a sub-property such as mainEntity, is it still valid to use more than 1 mainEntity for that particular CreativeWork? Or you suggest using mainEntity for the "main-est" thing, and then use about for the others? Thank you!
main should indicate the “main-est”, yes
On Sun, 3 Sep 2023 at 23:01, Marcelo Wilkorwsky @.***> wrote:
Hi! I have seen many web pages, and also articles, suggesting the usage of the "about" property more than once, indicating that the webpage is about more than 1 thing. ...But when we use a sub-property such as mainEntity, is it still valid to use more than 1 mainEntity for that particular CreativeWork? Or you suggest using mainEntity for the "main-est" thing, and then use about for the others? Thank you!
— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/3368, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGPNKA5KFIU7MLFASEDXYT447ANCNFSM6AAAAAA4JSOOLM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thank you @danbri for your reply!
1- In which cases would you consider the usage of 'about' to be more appropriate than 'mainEntity,' and vice versa? 2- Does using more than one 'mainEntity' cause validation issues, or is it simply a matter of good practice? 3- If you have, let's say, three entities on a webpage that you consider very important, would you use three 'about' elements, or would you try to select one as the 'mainEntity' and the other two as 'about' elements?
Regards!
No easy answer
The markup ought to tell the truth
Exact details have a lot of practical pragmatic considerations- it is often best to start from information about data-consuming applications. That can help you understand possible impact/use, as well as the data structures that consumers are looking for
On Mon, 4 Sep 2023 at 15:37, Marcelo Wilkorwsky @.***> wrote:
Thank you @danbri https://github.com/danbri for your reply!
1- In which cases would you consider the usage of 'about' to be more appropriate than 'mainEntity,' and vice versa? 2- Does using more than one 'mainEntity' cause validation issues, or is it simply a matter of good practice? 3- If you have, let's say, three entities on a webpage that you consider very important, would you use three 'about' elements, or would you try to select one as the 'mainEntity' and the other two as 'about' elements?
Regards!
— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/3368#issuecomment-1705377789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGOA44RTHP23C5FNLBDXYXRT7ANCNFSM6AAAAAA4JSOOLM . You are receiving this because you were mentioned.Message ID: @.***>
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
The issues is - Google Schema Verfifier kinda disagree with Schema.org on that topic (prooflink). Should Schema.org reconsider CreativeWork::mainEntity type to Thing | array<Thing>?
Hi @LeTraceurSnork ,
I noticed that in the example provided from Google's structured data documentation, multiple FAQs are indeed included within a mainEntity array, indicating this is supported by Google.
Could you clarify if your suggestion was about aligning Schema.org's documentation with this practice? Or perhaps there is another specific issue you're encountering with multiple mainEntity use?
The word “main” means we are pointing at one thing. It is probably best to think of the Google usage as a shorthand for a thing which is a kind of bundle of all the things they list.
Json-ld syntax can be confusing here since it uses an array to indicate repeated properties, although the areay itself is not an item in the graph (as eg an ItemList would be). Rather it is a way of encoding that graph in json.
On Wed, 3 Jul 2024 at 13:04, Marcelo Wilkorwsky @.***> wrote:
Hi @LeTraceurSnork https://github.com/LeTraceurSnork ,
I noticed that in the example provided from Google's structured data documentation, multiple FAQs are indeed included within a mainEntity array, indicating this is supported by Google.
Could you clarify if your suggestion was about aligning Schema.org's documentation with this practice? Or perhaps there is another specific issue you're encountering with multiple mainEntity use?
— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/3368#issuecomment-2205917944, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGJY7XC5VDUYQBIF3O3ZKPSFXAVCNFSM6AAAAABKJJFARGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBVHEYTOOJUGQ . You are receiving this because you were mentioned.Message ID: @.***>
No cardinality is implied in any property in schema.org. So in the terms of this thread, mainEntity already goes to Thing | array<Thing>. That's one of its strengths and weaknesses.
AFAIR, the team that built FAQ didn't want to require explicit ItemList syntax to specify a list of question/answer pairs that should be the main contents of those pages. So they used the allowed (but probably not ideal) multiple cardinality of mainEntity. So it's completely valid schema.org. It's just colloquially kinda ugly.
In general though, even at Google we usually prefer a single thing there. But if you have to struggle to think what the main entity is between three things, chances are it doesn't have a clear main entity. So don't use it. It's meant for cases where there is a very clear main entity. A webpage with a recipe generally has a recipe main entity. A product page generally will use that as the main entity. A wikipedia article fully about a certain person would have them as the main entity. If it's a news article that is mostly unstructured text and sort of focuses on a couple people but one person mostly, I probably wouldn't bother with mainEntity. Your time is probably more valuable elsewhere.
The cardinality is not there in a machine readable form (eg Owl:FunctionalProperty) but we have never tried to capture the full real world semantics in that way.
By analogy, we also do not say anywhere formally that the types PostalAddress and Recipe are mutually disjoint. However their natural language definitions (including their supertypes) make it pretty clear that there are no things fairly described as having those two types simultaneously. It is similar with mainEntity.
Or https://schema.org/birthDate - it’s just a fact about dates of birth that things are only born once.
There are always possible corner cases, eg caterpillars, certain religious believers, and some monarchs with official birthdates, … might be said to have multiple (re)birthdates. But these are pretty extended cases and would probably be modeled better another way. Same with “main entity” being anything other than a single thing. It’s just the way the word works.
On Wed, 3 Jul 2024 at 16:30, Ryan Levering @.*** wrote:
No cardinality is implied in any property in schema.org. So in the terms of this thread, mainEntity already goes to Thing | array. That's one of its strengths and weaknesses.
AFAIR, the team that built FAQ didn't want to require explicit ItemList syntax to specify a list of question/answer pairs that should be the main contents of those pages. So they used the allowed (but probably not ideal) multiple cardinality of mainEntity. So it's completely valid schema.org. It's just colloquially kinda ugly.
In general though, even at Google we usually prefer a single thing there. But if you have to struggle to think what the main entity is between three things, chances are it doesn't have a clear main entity. So don't use it. It's meant for cases where there is a very clear main entity. A webpage with a recipe generally has a recipe main entity. A product page generally will use that as the main entity. A wikipedia article fully about a certain person would have them as the main entity. If it's a news article that is mostly unstructured text and sort of focuses on a couple people but one person mostly, I probably wouldn't bother with mainEntity. Your time is probably more valuable elsewhere.
— Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/3368#issuecomment-2206564419, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGK3NJF5B4SD4RLYSNLZKQKKHAVCNFSM6AAAAABKJJFARGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBWGU3DINBRHE . You are receiving this because you were mentioned.Message ID: @.***>