Schema architecture

Hi everyone

I was going through an earlier type hierarchy example I had posted and
spotted a mistake, while updating it though I thought I should put it
forward for serious consideration. I'm only new to the community so I don't
want to make too many suggestions and give the wrong impression, and I
understand the difficulty of changes, but the long term benefits seem
significant.

Here is the outline:

Due to lack of clear meaning I want to suggest removing the following
high-level types and moving their properties higher in the type hierarchy:





*CreativeWorkIntangibleProduct*


And the same for these lower-level types:



*CivicStructureLandmarksOrHistoricalBuildingsLocalBusiness*


In my earlier example type hierarchy there was a missing type, equivalent
to Class, which I've added here in orange. I've also marked where types of
types would start, the pattern repeating as needed:

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


I've also corrected the example of properties being moved higher in the
type hierarchy. Moving many properties to *Thing* and *Type* could improve
the flexibility of Schema and its potential for cross-domain use:

*Thing*
    height
    width
    depth
    weight
    material
    color
    offers
    predecessorOf
    successorTo
    variantOf
        *Event*
            startDate
            endDate
            duration
        *Person*
            givenName
            familyName
        *Place*
            openingHoursSpecification
*        Type*
            heightOfTypicalInstances
            widthOfTypicalInstances
            depthOfTypicalInstances
            weightOfTypicalInstances
            materialOfTypicalInstances
            colorOfTypicalInstances
            offersOfTypicalInstances
            predecessorTypeOf
            successorTypeTo
            variantTypeOf


Similarly I've corrected the example that shows the pattern being applied -
iPhone instances and iPhone types:


*Thing*
*    Phone*
*        MobilePhone*
*            iPhone*
*                iPhone7*
*                iPhone8*
*                iPhoneX*
                    iPhone X (serial number 00000001)
                    iPhone X (serial number 00000002)
                    iPhone X (serial number 00000003)
*    Type*
*        ThingType*
*            PhoneType*
*                MobilePhoneType*
*                    iPhoneType*
                        iPhone 7
                        iPhone 8
                        iPhone X


With this approach you get the added benefit of no longer needing Product
or its subtypes, which means:

   - No undecidable questions about whether a type should be a subtype of
   Product.
   - No specialized logic, i.e. ProductModel subClassOf Product.
   - No redundant types, i.e. IndividualProduct.

Product and ProductModel could remain in Schema as long as needed, the
description pages could perhaps be updated with a recommendation to use
Thing and Type instead. Maybe supersededBy
<https://meta.schema.org/supersededBy> statements could also be used here:

   - *Product* supersededBy *Thing*
   - *ProductModel* supersededBy *Type*

Schema might become simpler and more scalable with this sort of approach.

I'd love to get a number of views, and also discover if there's actually
any demand for this sort of change.

Anthony

Received on Saturday, 23 June 2018 23:22:30 UTC