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

Closed
unor opened this Issue Jul 31, 2014 · 12 comments

Projects

None yet

6 participants

@unor
Contributor
unor commented Jul 31, 2014

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
Contributor

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 danbri added the python code label Aug 12, 2014
@danbri danbri added this to the sdo-gozer release milestone Jan 21, 2015
@danbri danbri self-assigned this Jan 21, 2015
@danbri danbri changed the title from Enhance the h1 (breadcrumb) so that it shows all parent types to Show multiple types (e.g. enhance h1 (breadcrumb) so that it shows all parent types) Jan 21, 2015
@danbri
Contributor
danbri commented Jan 21, 2015

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
Contributor

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
Contributor
mfhepp commented May 7, 2015

+1

@danbri
Contributor
danbri commented May 12, 2015

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

@chaals
Contributor
chaals commented May 12, 2015

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

@unor
Contributor
unor commented Jun 4, 2015

→ possible solution in #567

@danbri
Contributor
danbri commented Jun 8, 2015

Fixed in #567 - thanks @Dataliberate :)

@danbri danbri closed this Jun 8, 2015
@danbri
Contributor
danbri commented Jun 8, 2015
@mfhepp
Contributor
mfhepp commented Jun 9, 2015

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
Contributor
danbri commented Jun 9, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment