- 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