Intangible: everything is misc... can we add useful subtypes to organize it a little?

[danbri]

http://schema.org/Intangible (reasonably enough given its scope) contains a very wide range of types.

Currently there are many immediate subtypes. Can we organize them a little better without getting lost in abstract theory?

Current subtypes of Intangible

AlignmentObject, Audience, Brand, BroadcastChannel, BusTrip, Class, DataFeedItem, Demand, EntryPoint, Enumeration, Flight, GameServer, Invoice, ItemList, JobPosting, Language, ListItem, Offer, Order, OrderItem, ParcelDelivery, Permit, ProgramMembership, Property, PropertyValueSpecification, Quantity, Rating, Reservation, Role, Seat, Service, ServiceChannel, StructuredValue, Ticket, TrainTrip

Note that Class and Property will likely be moved to a 'meta.schema.org' extension - #1059 which will somewhat hide them from the main list of intangibles.

[danbri]

(there may be more in extensions)

[rvguha]

In the spirit of doing this incrementally,

1. Some of these things are 'schema constructs'. So, let create a
   class called 'SchemaConstruct' (not particular about the name) and put
   ItemList, ListItem (really, we have both?), Class, Property,
   Enumeration, PropertyValueSpecification, Quantity and StructuredValue
   under it.
2. Some of these things are like a 'Contract' for a use. Lets say
   'UseContract'. Put Ticket, Invoice, JobPosting, Offer, Permit,
   Reservation, ProgramMembership under this.

We also should have some property saying that a certain node is for
schema internal use only and should not be used in markup. Something
like an abstract class.

[philbarker]

Both AlignmentObject and Role provide extra information about the relationship between two entities

[danbri]

@rvguha re "We also should have some property saying that a certain node is for
schema internal use only and should not be used in markup. Something
like an abstract class.", we could use the extension mechanism for this. We already have the RDFS-like terminology (domainIncludes etc.) tucked away in the meta.schema.org extension.

I was discussing today with @gmackenz and @vholland that there is some maintenance cost to the project where we have avoided adding artificial types, since it forces us to remember them explicitly when property/type associations are updated. For example we didn't make an "Offerable" supertype of Product or Service, which is partly how "offers" and its not-quite-inverse "itemOffered" feel slightly out of sync. I suggested that we could look into documenting some things in a "hidden structure for the project team" extension, or else as a collection of graph pattern unit tests that we run via SPARQL.

Also, thinking about possible subtypes, how would you suggest handling something like a "MenuItem"? (#1288); is it contract-like?

[thadguidry]

@danbri For me, MenuItem is a Product (and an itemListElement)

[danbri]

The point is that we haven't created dozens (or 100s, 1000s, or millions) of subtypes of Product to provide types for things like MenuItem. But we will sometimes want types because there will be dedicated, type-specific properties to declare. The only non-infrastructural subtype of Property is Vehicle, and I suspect if we had made more progress in the ecosystem towards multiple-independently-typed entities even that wouldn't need to be handled as a Product subtype.

[thadguidry]

@danbri Ah gotcha now. I dislike bucket types however. Types or subtypes without any properties under them. So if we make some, lets have a least 1 property under them. :)

[mfhepp]

Related issue: When defining menues, you need to be able to specificy configuration options ("2 out of 10 side-servings", "ice-cream or fruits as a desert") and availability times ("pizza only from 18:00 to 21:00") and time-limited discounts ("happy hours - all drinks for USD5 Fridays from 18:00 - 21:00").

[iainhallam]

Seems like BusTrip, Flight and TrainTrip ought to be part of a Journey type.

[thadguidry]

@iainhallam TransportationMode instead.