Re: Schema architecture

That's ok. Would substantive changes be possible with a more planned
evolution though, like releases with general goals for example? A great
example is the process used for the Swift programming language:

Swift Evolution Process
<https://github.com/apple/swift-evolution/blob/master/process.md>


The goals for Swift 5.0 for example (expected early 2019) help align the
community's work:

Swift 5.0 <https://github.com/apple/swift-evolution/blob/master/README.md>


To organize discussions they have categorized forums:

   - Using Swift
   - Development
   - Evolution

That way people can propose technical changes without scaring away people
with everyday-use questions (like I've probably been doing, sorry).

There's even a place to pitch changes:

Swift Forums - Latest Pitches <https://forums.swift.org/c/evolution/pitches>


It lists "Commonly Rejected Changes" to avoid repetitive discussions.

Then changes like I'm suggesting could be targeted at say Schema 6.0 or 7.0
for example.

Thanks for the honest response.

Anthony


On Sun, Jun 24, 2018 at 3:41 PM Dan Brickley <danbri@google.com> wrote:

> On Sun, 24 Jun 2018 at 01:25, Anthony Moretti <anthony.moretti@gmail.com>
> wrote:
>
>> 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.
>>
>
> Respectfully, we are pretty unlikely to make these kinds of substantive
> changes. I'd be happy to have a call with you once I'm back at my desk
> (travelling home from
> https://www.poynter.org/news/fifth-global-fact-checking-summit-will-be-held-rome-june-2018
> ) to talk over some of the background to why Schema.org is taking the
> approach it is. There's no huge secret, and much of it can be found in the
> mail archives or in the ACM article
> https://queue.acm.org/detail.cfm?ref=rss&id=2857276
>
> Dan
>
> (schema.org Community Group chair, and project 'webmaster
> <http://schema.org/docs/howwework.html>')
>
> 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
>>
>