Show multiple types (e.g. enhance h1 (breadcrumb) so that it shows all parent types) about schemaorg HOT 14 CLOSED

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 [email protected] 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.

from schemaorg.

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."

from schemaorg.

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.

from schemaorg.

+1

from schemaorg.

+1

from schemaorg.

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

from schemaorg.

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

from schemaorg.

→ possible solution in #567

from schemaorg.

Fixed in #567 - thanks @Dataliberate :)

from schemaorg.

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

from schemaorg.

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.

from schemaorg.

@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.

from schemaorg.

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.

from schemaorg.

@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.

from schemaorg.