Proposal to add "relatedQuestion" to Thing

[DDeering]

I'd like to suggest/propose the addition of a "relatedQuestion" property to schema.org/Thing. The expected value of the property could then be schema.org/Question. I find that many web pages that are about certain entities such as, for example, products include common questions and answers about the entity. But currently there does not seem to be a clean and simple method to mark up such questions and answers and to nest them within the primary type. And I'm not sure that potentialAction > AskAction would be the way to go in such cases, but maybe I'm wrong.

So any thoughts on this would be appreciated. Thanks.

David

[danbri]

We are pretty conservative about adding stuff at the Thing level, but it seems worth looking for a pattern here. Can you give some URLs for example illustrative pages e.g. products with Q/A?

[DDeering]

Thanks Dan. I suggested adding the property at the Thing level only because of how many subtypes of Thing could benefit from the property such as products, services, events, places and so on. But that could be handled however you think is best.

Here are just a few random examples that I think might benefit from the use of the relatedQuestion property:

http://www.microsurfacecorp.com/Nickel-Silicon-Carbide-Codiac-Coating.php
http://www.homedepot.com/p/DEWALT-20-Volt-MAX-Lithium-Ion-Cordless-Combo-Kit-5-Tool-with-Bonus-Cut-Off-Tool-and-Bluetooth-Speaker-DCK520D2DCR006DCG412B/206824797 (this product page has multiple given answers but I think the property could still apply)
https://www.vat19.com/item/toastit-toaster-bags
http://vanburendriveintheatre.com/enjoy/

It's true that some of these questions and answers and facts could be handled with other markup structures but I think some cannot. But I welcome any feedback and ideas.

Thanks.

David

[danbri]

We already have "about" which can reference any kind of thing. Can that be exploited as-is?

[DDeering]

I think the "about" property would work great for questions on pages such as FAQ pages or forum topic pages. But I don't think it would work so great on a product page, for example. The question would then become the top-level entity (Question > about > Product > offers > Offer ...). But if the "relatedQuestion" property was added, it would provide a clean and simple solution for including questions and answers about various entities. And including questions in current markup structures would not require completely changing the markup structure and/or adding a separate block of code or script to the page.

If you're hesitant to add the "relatedQuestion" property at the Thing level, would you at least consider adding the property to Product, Event, Place and Organization, Dan? While I personally believe that the property could find use on every type of entity, those 4 types would probably use it the most.

[betehess]

I agree with @danbri that schema:about already does the job.

We actually have a very similar use-case. Still a work-in-progress on our side, but it would look like that:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "QAPage",
  "url": "http://www.apple.com/support/iphone/",
  "name": "iPhone Support",
  "description": "Learn how to set up, backup and use your iPhone ...",
  "about": {
    "@id": "http://www.apple.com/iphone-6s/#thing",
    "url": "http://www.apple.com/iphone-6s/"
  }
}
</script>

http://www.apple.com/iphone-6s/#thing would really be defined in http://www.apple.com/iphone-6s/. We might drop the url for that guy from that snippet.

[DDeering]

Thanks for your thoughts, Alexandre. But I'm still not completely convinced that "about" is the approach to take in the examples I listed above. At the moment, we simply can't nest a Question within a Product markup using the about property. So while we can do this: Question > about > Product, we can't do this: Product (or Event or Place, etc) > has-a-question-about-it > Question. In such instances, the about property is one-directional.

So in my opinion, adding a relatedQuestion property would be a way to fix that. Or if we want to keep things tight, maybe we can go with hasQuestionAbout.

[betehess]

@DDeering could you provide an actual example as JSON-LD using one of your proposed additions? It will be easier to understand the intent.

[jvandriel]

Looking at the discussion so far, while also looking at the request to add 'associatedMedia' to schema.org/Thing (#292), made me wonder if we can merge the two requqests by adding a new property 'associatedWork' (or 'relatedWork'), with a domain of schema.org/Thing and a range of schema.org/CreativeWork?

This way anything can refer to any question/article/video/etc about it.

eg,

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Product",
  "name": "Explosive tennis balls",
  "relatedWork":
  {
    "@type": "Question",
    "text": "Do these explode on impact on target or when one hits them while serving?"
  }
}
</script>

but also

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "MedicalProcedure",
  "name": "Tummy Tuck",
  "associatedWork":
  {
    "@type": "VideoObject",
    "name": "How to find out if a Tummy Tuck is right for you?"
  }
}
</script>

[danbri]

@DDeering we have around 1000 properties and 600+ types so if we can get away with using "about" that can save us a lot of potential complexity. Question is just one kind of CreativeWork that could be about a Product; if we add hasQuestionAbout, do we follow up with adding (to Thing) properties for hasArticleAbout, hasBlogAbout, hasBookAbout, hasReviewAbout, hasTVEpisodeAbout etc etc.? At least we'd want to find the commonality there and go for something like "hasCreativeWorkAbout" or "topicOf" ...

I appreciate the syntax/nesting frustrations though. In general we have avoided coming up with reverse names for all properties, but have done so when they seem likely to be desired and when there's a nice obvious name for the reverse direction. It has been hard to define clear guidelines for this. It feels like an explicit reverse property here might be useful.

[jvandriel]

And by the way, by not adding such a property (or both) to schema.org/Thing forces folks to having to use fragment identifiers to make this work (in case a Product is a top level entity) Based on what we can do with schema.org now we'd get:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@id": "#MainEntity"
  "@type": "MedicalProcedure",
  "name": "Tummy Tuck",
  "mainEntityOfPage":
  {
    "@type": "MedicalWebPage",
    "@id": "http://www.example.com/procedures/tummy-tuck"
  }
}
</script>

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "VideoObject",
  "name": "How to find out if a Tummy Tuck is right for you?",
  "about":  {"@id": "#MainEntity"}
}
</script>

[danbri]

@jvandriel - I edited your markup - it needs left padding with whitespace to display property here.

[jvandriel]

Thanks @danbri, and I have to say I like your 'topicOf' very much. Would make for nice and easy markup:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Product",
  "name": "Explosive tennis balls",
  "topicOf":
  [
  {
    "@type": "Question",
    "text": "Do these explode on impact on target or when one hits them while serving?"
  },
  {
    "@type": "VideoObject",
    "name": "Explosive tennis balls? They now exist"
  }
  ]
}
</script>

[DDeering]

topicOf? I like it. I like hasCreativeWorkAbout as well. I think either would work as a solution to this issue and to several others as Jarno's markup shows.

I'm not trying to make your work harder, Dan, I'm just trying to fill in some gaps that I regularly come across in my work, that's all.

[danbri]

@DDeering sorry I didn't mean to sound ungrateful - it is super useful hearing from people actually using this stuff. I was just trying to dig down to get the underlying requirement...

[DDeering]

@danbri Glad you did. And I'm glad that you can take specific ideas and broaden the solutions to make them useful to many. I'm happy with either one of those properties you suggested.

[jvandriel]

So does this mean it's now time to open up a new issue: "Proposal: Add 'topicOf' to schema.org/Thing" and close the ones related to the topic (like this one, #292, and any other still floating around)?

[betehess]

I agree with the need of a topicOf as reverse property for about.

[mfhepp]

As a general comment: Modeling the inverse property can often be a handy pattern for things to say about Thing while keeping the amount of properties for Thing at a minimum. It does not clutter schema.org as much if we have lots of properties that accept Thing as their range as compared to properties with Thing in their domain.

Martin

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 29 Apr 2016, at 01:33, Alexandre Bertails notifications@github.com wrote:

I agree with the need of a topicOf as reverse property for about.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[jaygray0919]

@mfhepp Would you add one more level of detail to your statement? It's an important concept and might be worth a bit more elaboration. It's a post I'll bookmark.

[mfhepp]

I simply meant the following:

Most properties (relationship types) can be defined either way, like

Peter memberOf ACME

vs.

ACME hasMember Peter

"Domain" means the type or type to which a property is applicable. "Range" means the type or types of allowed values.

If we assume "Peter" is an instance of the type "Person" and "ACME" an instance of the type "Organization", then the domain of "memberOf" is "Person" and that of "hasMember" is "Organization".

If we want to keep the number of properties small for the type "Person", we can substitute "memberOf" by "hasMember".

Some modeling approaches recommend defining both variants of the same relationship type and marking them as inverses of each other, so a computer can infer the same information from either way.

In schema.org, we tend to avoid inverses and aim at defining the more popular direction only (with a few exceptions).

Hope that helps.

Martin

On 29 Apr 2016, at 07:32, jay gray notifications@github.com wrote:

@mfhepp Would you add one more level of detail to your statement? It's an important concept and might be worth a bit more elaboration. It's a post I'll bookmark.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[jaygray0919]

TY for the explanation. IMHO you should write this up as a more formal post for wider exposure. We have a number of competent Curators who follow the schema.org grammar, But many do not necessarily understand the design point you made in your original post. I am still re-reading it to make sure I REALLY understand. Our folks watch this group to monitor changes to schema.org. Every now and then more profound ideas pop out, and I try to bring it to their attention. That's why I jumped on this post. TY again Martin.

[danbri]

Yes, this comes down to exploiting an asymmetry in our psychology. Although the underlying logic doesn't care, we feel that properties are "attached to" or "part of" the types they apply to, more than those whose values they take. So "alumni" is attached to (and risks "cluttering") EducationalOrganization whereas alumniOf is similarly seen as being attached to (and risks "cluttering") Person.

This is closely related to the idea of an object-relational impedance mismatch, which is just a fancy way of saying that there's a clash between thinking in terms of kind of objects and their properties, versus thinking in terms of collections of unordered raw factual statements.

I would caution against over-exploiting this phenomena (i.e. that incoming properties to a type don't feel like they're cluttering it). It is also possible for incoming property lists to become cluttered, both conceptually (it makes our design harder to learn) and in terms of site/documentation navigation. For example see the "Instances of Person may appear as values for the following properties" section of http://schema.org/Person for a popular type. Whereas the equally important http://schema.org/Event has only 7 properties whose values are Event, there are already 60 properties with Person-valued properties. The impact is less obvious with incoming properties, but it still has a tangible, measurable downside to the clarity and usability of our vocabulary (and its documentation).

[jaygray0919]

IMHO, and when you, Martin, et. al. have time, s discussion of the above ideas would be very useful to Curators/Publishers. We are working at the limits of schema.org - wanting to use it properly, and then - properly - compose additional information to make our graphs more comprehensive. We've had to do a lot of rework as we migrate existing compositions from OBO-centric domains to a schema.org-centric domain. Ditto with a number of "W3C" ontologies. We need to implement ONE design. It's not easy, and help from experts like you and @mfhepp makes it easier.

[danbri]

Yes, I agree a lot of assumptions have been under-articulated. There's a "how we work" set of documents starting to come together, and modeling issues need to be covered. https://www.w3.org/community/schemaorg/how-we-work/ will be an entry point....

[github-actions]

This issue is being tagged as Stale due to inactivity.