Re: MedicalAudience - part of 2 different superClasses?

Got it, thanks for the explanation.


2014-08-13 22:32 GMT+02:00 Dan Brickley <danbri@google.com>:

> On 13 August 2014 20:42, Jarno van Driel <jarnovandriel@gmail.com> wrote:
> > Maybe I'm asking something obvious but I'm a bit confused about
> > schema.org/MedicalAudience.
>
> (from the rdfa/rdfs)
>
> <div typeof="rdfs:Class" resource="http://schema.org/MedicalAudience">
> <span class="h" property="rdfs:label">MedicalAudience</span>
> <span property="rdfs:comment">Target audiences for medical web pages.
> Enumerated type.</span>
> <span>Subclass of: <a property="rdfs:subClassOf"
> href="http://schema.org/Audience">Audience</a></span>
> <span>Subclass of: <a property="rdfs:subClassOf"
> href="http://schema.org/MedicalEnumeration">MedicalEnumeration</a></span>
> <span>Subclass of: <a property="rdfs:subClassOf"
> href="http://schema.org/Enumeration">Enumeration</a></span>
> <span>Subclass of: <a property="rdfs:subClassOf"
> href="http://schema.org/PeopleAudience">PeopleAudience</a></span>
> </div>
>
> > It has 2 different superClasses (Audience & PeopleAudience), which by
> itself
> > isn't strange, but what confuses me is that in the 'type-tree' (don't
> know
> > what else to call it) PeopleAudience is also MedicalAudience's sibling.
> >
> > So I was wondering, can a type be a subClass & sibling of another type
> > without any problem or is it an error?
>
> I don't think its inconsistent, but it might be redundant. There are
> some cases due to the old way the site was built, where we had to make
> some cludges when changing the hierarchy. You can see something a
> little similar around the 'expected values' for properties like
> http://schema.org/episode which needlessly list subtypes.
>
> I don't see any reason to keep
>
> <span>Subclass of: <a property="rdfs:subClassOf"
> href="http://schema.org/Audience">Audience</a></span>
>
> ... since it's implied by 'subclassof: PeopleAudience'. My hunch is
> that it's there either as an implementation hack needed by our old
> codebase, or as an oversight.
>
> Dan
>