-
Notifications
You must be signed in to change notification settings - Fork 825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a mainEntity property that relates a page to the main thing it describes + inverseOf mainEntityOfPage #301
Comments
Another use case: using tools that return a graph, knowing the mainEntity gives you a useful entry point into a complex linked data structure. |
That sounds like a loopback that does not solve the problem "the mainEntity on this page is SOMEWHERE on this same page?!?!?" WTF ? +1 for mainEntity. I think it is clear and we know what we want to accomplish. I see very little argument against or change the proposal. The examples make sense. I like the |
I think it's a requirement that you be able to refer to the main entity in markup on other pages by the canonical URL of that leaf page. However, in your example, it's the WebPage entity that gets the canonical URL. |
+1 for the proposal. Suggested addition:
|
seems to make sense? How to avoid terminological overlap with Looking at http://topbraid.org/schema/ , how would |
@jasondouglas hopefully we can define the property without requiring global agreement on URL use. But would a tweak to the example that gave the WebPage entity a trivially different URL help? (in this example one ending with a final '#' ): Microdata:
RDFa:
JSON-LD:
If mainEntity is a link between different things (a doc and the entity) they'll need different identifiers. It seems much easier to agree that having such a property is useful than to persuade millions of sites to choose a particular pattern for assigning URLs. Do you have a preferred best practice that should be encouraged? |
@danbri I think focusing on the inverted relationship is more intuitive:
You could complain about uniqueness, but that's an issue with any approach (I can specify multiple values for mainEntity too). |
@jasondouglas I toyed with those designs too. I think we're close. How about adding the relation named in both directions (mainEntity and mainEntityOfPage), but having the relationship to a document being the preferred usage. Whether the boolean fallback option works depends on processing scenarios - e.g. if you're merging triples from several such documents you might be out of luck. I'm not worried about enforcing uniqueness, people will always mess up until there are tools and incentives that help them do a cleaner job. |
I had a look at @reverse in JSON-LD. It isn't especially pretty for this, and helps makes @jasondouglas 's case to name the relationship in the other direction:
(if the schema.org JSON-LD file declared mainEntity as taking id values I think this could just be "@reverse": { "mainEntity": "#"}, ...) mainEntityOfPage would then mean much the same as foaf:isPrimaryTopicOf, i.e. it "relates something to a document that is mainly about it.". I wonder whether the "Page" part is worthwhile -- e.g. podcasts, broadcasts, .avi files might all also have main entities. |
I spent too much time working in this space at the graduate level to be However, there does seem to be a possible question how such a property I've been treating that property as being roughly equivalent to the OWL HasKey(schema:Thing (schema:sameAs) ()) This is basically ignoring the contents of the web page (WebPage?) ; the I'm sure everything will go wrong because blank nodes. |
Huh, that makes me wonder if we're overthinking this. Could it just On Thu Jan 29 2015 at 12:47:08 PM Simon Spero notifications@github.com
|
Intriguing, though I don't know whether people responsible for content payload will always be in a position to ensure the CMS or whatever doesn't add WebPage properties for the document itself. |
The test for overthinking on this is whether you can't remember if you |
On Jan 29, 2015, at 12:10 PM, Dan Brickley notifications@github.com wrote: "I had a look at @reverse https://github.com/reverse in JSON-LD. It isn't especially pretty for this, and helps makes @jasondouglas https://github.com/jasondouglas 's case to name the relationship in the other direction [...]" We did at @itemprop-reverse to Microdata (experimentally, anyway) for (if the schema.org JSON-LD file declared mainEntity as taking id values I |
+1 for the proposal (as if I could be against it, hehe) |
I've updated the description above to include in the proposal a property named in the opposite direction, mainEntityOfPage. Although it might seem decadent and redundant having both directions, we do this sometimes in schema.org where the information is particularly useful, on the basis of our rule of thumb which is to make things easier for publishers even if it makes things slightly harder for consumers. |
An example,
Excerpt from data shows 3 RadioEpisode entities. But which one is the single primary focus of the page?
|
It's not marked up as so, but wouldn't the RadioSeries "Steve Wright in the Afternoon" be the main topic? |
The series is marked up via: I'd read this as that http://www.bbc.co.uk/programmes/b006wr4r is mostly about that series, whereas http://www.bbc.co.uk/programmes/b03gg84h and http://www.bbc.co.uk/programmes/b03fflnx are mostly about specific episodes in that series. The Series page i.e. http://www.bbc.co.uk/programmes/b006wr4r has this:
|
Also, I have the stupid jingle from the 80s stuck in my head now.
|
Another example can be found on: http://www.imdb.com/title/tt1617661/, which contains 3 Top Level Entities: Movie, VideoObject and another VideoObject. Google's SDTT: https://developers.google.com/webmasters/structured-data/testing-tool/?url=http://www.imdb.com/title/tt1617661/?ref_=inth_ov_tt |
Is there any chance sponsors will make an announcement when either of 'm is ready to support IMHO this is one of those cases where the sponsors should provide support before there are enough use cases as one my biggest worries is that folks won't start using it if they notice that it prevents them from getting enriched search result snippets. |
+1 |
At this point, sdo-gozer should be considered a work-in-progress (and in flux). Things that are in gozer but not yet in schema.org may continue to evolve as we talk things through, get wider review, yadda yadda. Whether and when search engines make use of the vocabulary is another matter. |
Suggestion for the example/examples when this eventually released based on the current example at http://sdo-gozer.appspot.com/mainEntity. Namely, that two entities should be present. That is, would there any reason to declare "the primary entity described in some page or other CreativeWork" if there were no other entities described? Both "main" and "primary" infer the existence of "secondary". |
Filing this for gozer. We're nearly there with it. |
I agree with you @Aaranged - would this work for you? mainEntityOfPage
mainEntity
|
Thanks @jvandriel - both these and the revised gozer examples are much clearer. |
Should we have some longer description somewhere about proper usage of mainEntity v. sameAs v. about v. url? Something along the lines of the below, using the initial description from @danbri above as a start? Also, is there an existing mechanism to specify the cardinality of the properties so that we can say that mainEntity should be single-valued, while mainEntityOfPage can be multi-valued? Or do we rely on the property descriptions for that? Draft longer description (to be put in documentation somewhere?): Many (but not all) pages have a fairly clear primary topic, some entity or thing that the page describes. For example a restaurant's home page might be primarily about that Restaurant, or an event listing page might represent a single event. The mainEntity and mainEntityOfPage properties allow you to express the relationship between the page and the primary entity. Related properties include sameAs, about, and url. sameAs and url are both similar to mainEntityOfPage, but sameAs and url should be reserved to refer to more official or authoritative web pages, such as the item’s Wikipedia page or official website. mainEntityOfPage can be used for any page, including those not recognized as the authoritative for the entity. For example, for a product, sameAs might refer to a page on the manufacturer’s official site with specs for the product, while mainEntityOfPage might refer to pages on various retailers’ sites with details for the same product. about is similar to mainEntity, with two key differences. First, about can refer to multiple entities/topics, while mainEntity should be used for only the primary one. Second, some pages have a primary entity that itself describes some other entity. For example, one web page may display a news article about a particular person. Another page may display a product review for a particular product. In these cases, mainEntity for the pages should refer to the news article or review, respectively, while about would more properly refer to the person or product. |
Thanks @tmarshbing - I think you're right, this deserves a more careful write up. I would be fine including something like this in the term's main description (too?). We might also mention or include it in docs/datamodel.html (which could also do with a refresh). |
@tmarshbing - I've added most of your text into http://sdo-gozer.appspot.com/mainEntityOfPage (tweaked a bit near the start to distinguish sameAs vs url slightly differently). The property names need hyperlinking, but apart from that I think it is an improvement. I'm marking this as closed (ever optimistic) but please re-open or comment here if more is needed. |
It has also been suggested that we should allow a simple boolean value, e.g. on some page it might say mainEntityOfPage: "true", as a property of the entity. This doesn't work well when asserted in a different page but could be a reasonable shorthand. |
Looks good. I believe the introductory text on http://sdo-gozer.appspot.com/mainEntityOfPage is suitable for both properties. The latter part is about |
If I might make a suggestion, how about something like this for the third paragraph: The url property should be reserved to refer to the webpage where the thing it has been labelled for can be found, whereas the sameAs property relates to webpages that indirectly identify it. The mainEntityOfPage property serves to clarify which of several entities on a webpage is the main one for that page. I found the current paragraph a bit hard to digest (feel free to reject or modify of course). |
An even braver attempt? :) Related attributes and properties include @itemid, @resource, @id, sameAs, about, and url. The url property should be reserved to refer to the webpage where the thing it has been labelled for can be found whereas the sameAs property relates to webpages that indirectly identify it. @itemid (microdata), @resource (RDFa) and @id (JSON-LD) can be used to uniquely identify things that are being described on a page. The mainEntityOfPage property serves to clarify which of several entities on a webpage is the main one for that page. |
9d1c502 fixes an oversight from the earlier commit. By listing URL as an expected type, we add this property to those declared in our JSON-LD context file i.e. http://sdo-gozer.appspot.com/docs/jsonldcontext.json as defaulting to @id types. This means we can have a more convenient shorthand for relative URLs.
Can now be,
|
The docs about "mainEntity " is not clear (zero example for something is a little abstract). Please fix this. |
Many (but not all) pages have a fairly clear primary topic, some entity or thing that the page describes. For example a restaurant's home page might be primarily about that Restaurant, or an event listing page might represent a single event. Sometimes metadata (including inbound links) exploits the obvious association between page and the thing it describes, even blurring the distinction between the two.
The proposal here is to add a new property, 'mainEntity' which is a relationship between a document and the main thing that it describes.
Update: Feb5th based on discussion below and other feedback, am proposing also adding an inverseOf mainEntity, mainEntityOfPage.
Goals
Non-Goals
Examples
A Restaurant homepage (in Microdata)
Taking an existing example of http://schema.org/Restaurant and expanding:
A MusicGroup described in page alongside related entities (e.g. JSON-LD)
Questions
Alternatives that do not work (for the purposes above)
The text was updated successfully, but these errors were encountered: