Re: Discussion topic: How to improve understanding and application of schema.org

If it helps, I've tried to put together my suggestions from last week on
making Schema easier. I realize a lot of people will disagree, and realize
most of it is unlikely to go through. I do hope though that in the spirit
of this thread it might help improve people's understanding of Schema, and
who knows maybe even inform future tweaks. I welcome any feedback or
questions.

All types could ideally exist in pairs, following a naming pattern such as:

*BaseType*

*BaseTypeType*


This pattern scales in the rare instances required:

*BaseTypeTypeType*

etc.


The "some or all" test for subtyping should be strictly followed:

If, and only if, *all* instances of one type are instances of another is it
a subtype.


Types without a clearly agreed meaning should be removed and their
properties moved to the parent type. Time-wasting debates have been caused
because of the lack of clear meaning of the following types:

*CreativeWork*
*Intangible*
*Product*


Combining the above points results in an arguably easier to learn, simpler
to use, and (importantly) more scalable type hierarchy. A partial example
of what it might look like (showing several subtypes of Place to
demonstrate how it scales):


*Thing*
*    Action*
*    Article*
*    Book*
*    Event*
*    Game*
*    Language*
*    Movie*
*    MusicRecording*
*    Organization*
*    Painting*
*    Person*
*    Place*
*        Airport*
*        Bridge*
*        Hospital*
*        Museum*
*        Park*
*    Reservation*
*    ThingType*
*        ActionType*
*        ArticleType*
*        BookType*
*        EventType*
*        GameType*
*        LanguageType*
*        MovieType*
*        MusicRecordingType*
*        OrganizationType*
*        PaintingType*
*        PersonType*
*        PlaceType*
*            AirportType*
*            BridgeType*
*            HospitalType*
*            MuseumType*
*            ParkType*
*        ReservationType*
*        TicketType*
*        VehicleType*
*        WebPageType*
*        WebSiteType*
*    Ticket*
*    Vehicle*
*    WebPage*
*    WebSite*


For greatest flexibility, and in the spirit of
volcanoes-can-have-fax-numbers, a guideline similar to the rule of three
<https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)> can
then be applied:

Whenever a property is used on more than two types move it to the parent
type.


Moving properties higher in the type hierarchy improves the flexibility of
Schema, and might address some of the cross-domain concerns people have.
Loading properties onto Thing is a good idea in my view, it achieves
maximum reuse.

A partial example of what it might look like:

*Thing*
    height
    width
    depth
    weight
    material
    color

    offers

    predecessorOf
    successorTo
    variantOf

        *Event*

            endDate

            startDate

        *Person*

            additionalName

            familyName

            givenName

*        ThingType*
            heightOfTypicalInstances
            widthOfTypicalInstances
            depthOfTypicalInstances
            weightOfTypicalInstances
            materialOfTypicalInstances
            colorOfTypicalInstances
            offersOfTypicalInstances
            predecessorTypeOf
            successorTypeTo
            variantTypeOf


The following are some other minor suggestions:

When naming things, the underlying model combined with the naming
convention above is enough to provide type-instance distinctions, so words
like the following are ideally avoided in type names:

Class
Category
Description

Entity

Individual
Instance
Model

Object

Occurence
Specification


(The exception is probably for subtypes of StructuredValue, where adding
"Description" or "Specification" to the end of all type names might
highlight that their instances have a different nature.)

On the full hierarchy <https://schema.org/docs/full.html> page, instances
of Enumeration (for example ActionStatusType, BoardingPolicyType, etc.)
could be in a different text style (if they should be listed on the page at
all). Also, to follow the pattern of the example type hierarchy above and
to give organization, a subtype of Enumeration, TypeEnumeration, could be
created:

*Enumeration*
*    TypeEnumeration*


For consistency's sake, the same could be done for structured values:

*StructuredValue*
*    TypeStructuredValue*


Also on the full hierarchy page, to be consistent with the Class section
that immediately starts with classes, the Data Types section could
immediately start with data types, not with the type "DataType".
Additionally, in a similar manner to Enumerations, the instances of
Boolean, True and False, could be in a different text style to the data
types (if they should be listed there at all).

I hope people might find this useful.

Anthony

On Sat, Jun 16, 2018 at 4:40 PM Thad Guidry <thadguidry@gmail.com> wrote:

> I've started the new "Help Our Users!" mission
> https://github.com/schemaorg/schemaorg/issues/1958
>
> -Thad
>
>