Show multiple types (e.g. enhance h1 (breadcrumb) so that it shows all parent types)

[unor]

Before I realized that types can have several parents, I was really confused why LocalBusiness shows me sometimes the breadcrumb "Thing > Place > LocalBusiness" and sometimes "Thing > Organization > LocalBusiness".

I think it would be nice to represent this fact also in the breadcrumb on top of the page (and not only indirectly in the property table).

A simple solution: Show one breadcrumb line per parent, sorted alphabetically.

This (or a more beautiful solution) has also the benefit that the tbody elements won’t change their order (depending on which breadcrumb you happen to get).

[Dataliberate]

I have an enhancement that handles this - Danbri and I are discussing how we get it into the code

~Richard

On 31 Jul 2014, at 19:57, unor notifications@github.com wrote:

Before I realized that types can have several parents, I was really confused why LocalBusiness shows me sometimes the breadcrumb "Thing > Place > LocalBusiness" and sometimes "Thing > Organization > LocalBusiness".

I think it would be nice to represent this fact also in the breadcrumb on top of the page (and not only indirectly in the property table).

A simple solution: Show one breadcrumb line per parent, sorted alphabetically.

This (or a more beautiful solution) has also the benefit that the tbody element won’t change their order (depending on which active breadcrumb you happen to get).

—
Reply to this email directly or view it on GitHub.

[danbri]

Merging in the entry at https://www.w3.org/2011/webschema/track/issues/20

Originally raised by Jason Ronallo,

    http://lists.w3.org/Archives/Public/public-vocabs/2013Jan/0140.html from Jason Ronallo.

    "The schema.org documentation should show multiple inheritance chains
    when there are multiple parents for a type. For instance a Hospital is
    a CivicStructure, MedicalOrganization, and EmergencyService. No matter
    which "Hospital" link you follow on the Full Hierarchy page you end up
    on the same http://schema.org/Hospital page, as you should. But the
    only hierarchy displayed is:

    Thing > Place > CivicStructure > Hospital

    It should also show the other inheritance chains:

    Thing > Organization > LocalBusiness > MedicalOrganization > Hospital
    Thing > Organization > LocalBusiness > EmergencyService > Hospital

    The design might be prettier or more compact than the above, but this
    data seems important for understanding the definition and possible
    uses of types that have multiple inheritance. It also helps to be able
    to look at other documentation pages to find definitions of those
    types and related markup examples."

[Dataliberate]

I think this is important to get into sdo-gozer.

Multiple types is not widely understood and it does not help when we are not clear when it occurs in Schema.org vocabulary documentation itself.

[jvandriel]

+1

[mfhepp]

+1

[danbri]

Didn't get to this due to major (and incomplete) code reorg, but will need to be getting to this soon.

[chaals]

OK. I agree that it will be helpful when it can happen.

[unor]

→ possible solution in #567

[danbri]

Fixed in #567 - thanks @Dataliberate :)

[danbri]

For review see http://sdo-ganymede.appspot.com/LocalBusiness and below

[mfhepp]

Looks good.

Note that the "X" for closing the extension links to http://appspot.com/ on the development server. I assume that in the live system, it would get you to http://schema.org/ and that the heuristic for generating that URI fails for appspot.com deployments.

[danbri]

@mfhepp yeah I'm overhauling all that before we launch any actual extensions. AppEngine gets confused about host names too, e.g. if you serve as webschemas.org it tells you it was webschemas.appspot.com; throw subdomains into the mix and things get tangled quickly. That was why I backed off and made sure we could push some things out into jinja2 templates for maintainability.

[RehanSaeed]

The machine readable https://schema.org/docs/tree.jsonld tree structure showing all schema.org classes has not been updated to show multiple inheritance. I've raised the issue #1679 to address this issue.

[danbri]

@RehanSaeed yes - that was a pragmatic decision I made when building the tree representation. Perhaps in the future we might do something like give each type an annotation indicating its primary/dominant supertype, but for now the code simply picks one supertype so that we get a clean tree structure with no duplication. I'll respond also in #1679.