- From: Anthony Moretti <anthony.moretti@gmail.com>
- Date: Sat, 23 Jun 2018 16:21:53 -0700
- To: "schema.org Mailing List" <public-schemaorg@w3.org>
- Message-ID: <CACusdfR-fefZzHTZc3Me0-4WF+d=eQzBhouLBD7hczQNrBPY2g@mail.gmail.com>
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