Manufacturing - proposed extension
We at SmartMfg are developing a manufacturing extension called "mfg" for schema.org.

The current state of our extension includes the following terms (with examples for markup):
- Industry: link
- ManufacturingOrganization: link
- ManufacturingService: link
- VolumeLevel: link
- anzsic: link
- gics: link
- icb: link
- manufacturesProduct: link
- mfgMaterial: link
- nace: link
- productionVolume: link
- qualityCertification: link
- serviceProvided: link
- sic: link
- sni: link
- trbc: link
- uksic: link
- High: link
- Low: link
- Medium: link
Note: the core 'industry' property has been edited as well to include the new "Industry" class in its range.
@reidyoder thanks for sharing this detailed proposal which obviously had a great deal of thought put into it.
I have a few high-level comments mostly arising from the supplied diagram.
- ManufacturingOrganization
- I would suggest making this a subtype of LocalBusiness. This brings together the properties of Organization and Place enabling a fuller description of all attributes of the Organisation and its location etc.
- industry Either within a mfg.schema.org extension definition broaden its domain to include ManufacturingOrganization, or potentially add Organization to its domain in the core for broader benefit.
- mfgOwns - not convinced is needed as described - I would suggest that a ManufacturingFacility (see below) would be better described as a department or subOrganization of a parentOrganization. Also it may well cause confusion with the inherited (from Organization) owns property.
- mfgServiceProvided - to fit with the normal Schema.org (Offer based) model this would be described as an Offer in the associated hasOfferCatalog inherited from Organization.
- ManufacturingFacility
- I suggest that this would also benefit from being a subtype of LocalBusiness. It would enable the description of its location, naming, contacts, and relationship with a parentOrganization.
- mfgFacilityWorker - employee would satisfy this need.
- ManufacturingService - what is special about a ManufacturingService that just using Service would not satisfy?
- ManufacturingTradeShow
- I think this has broader applicability and may be better proposed as a TradeShow subtype of BusinessEvent, or ExhibitionEvent in the core vocabulary.
- attendee - no need to modify it, it is already inherited from Event.
I would like to look at your proposal a bit further, but would be interested the thoughts of you and others before delving deeper.
~Richard.
@RichardWallis thanks for the reply.
I'm not sure if making ManufacturingOrganization a subclass of LocalBusiness makes sense. I'm looking through the the different subclasses of LocalBusiness and seeing things like "Library", "Dentist", "Animal Shelter", etc. These are small businesses that only serve a given community or city. A ManufacturingOrganization on the other hand has the potential to serve the whole globe. The description of LocalBusiness is "a particular physical business or branch of an organization". When we refer to ManufacturingOrganization, we are referring to the organization as a whole, not just a physical store or branched entity (especially since many manufacturing organizations don't have phyiscal stores, but online stores that distribute to various continents). You mentioned bringing together the properties Organization and Place, but I'm not sure if this is needed when the properties from Organization seem to suffice. I agree that ManufacturingFacility should be a subclass of LocalBusiness, given that a facility is one phyiscal entity.
I think changing the industry property in the core to include Organization in its range (and changing the property's description to fit) would be the most beneficial way to go. I also agree that it may be better to create a TradeShow subclass in the core instead of a ManufacturingTradeShow subclass in our extension. How exactly do I make small changes like these to the core and see it approved?
When I wrote that attendee should be modified for our extension, I should have clarified that I was referring to the range, not the domain. But looking at the range of the property now, I see that it can take the value of an Organization. I guess I was thinking that I would have to add ManufacturingOrganization to the range, but ManufacturingOrganization is indeed a subclass of Organization, so that should be fine to leave attendee unmodified.
I agree that mfgOwns is unnecessary. I think Organization's subOrganization property will work fine.
I agree that mfgServiceProvided could be covered by the hasOfferCatalog, but the OfferCatalog type seems to be a bit vague and "all-inclusive" to our disadvantage. We specifically want the property to descibe a provided manufacturing service. This sort of leads me to a question I have regarding your comments on mfgFacilityWorker and ManfacturingService. Aren't there advantages when searching for data to being specific rather than all-encompassing and thus vague? For example, if someone is specifically searching for a manufacturing service such as "micro machining" like in the example, wouldn't the results be less relevant if the data was only classified under Service (as opposed to ManufacturingService). This also makes me wonder what benefits using different range types for a property makes on search results. For example, the location property can take Place, PostalAddress, or Text. What difference does it make whether something is plain Text or something more specific like PostalAddress?
Please let me know your thoughts on all of this.
Thanks Richard for your helpful comments. My expertise is in Manufacturing so most of my comments will address the semantics of the manufacturing concepts that will be discussed in this thread.
The definition of ManufacturingOrganization should be broad enough that it can be applied to a company like Toyota as well as a small family-run machine shop.
My suggestion is to put our focus on Organization and Service boxes (in the proposed blueprint) and move one to the other types once we identify the key properties related to ManufacturingOrganization and ManufacturingService.
Thanks, Farhad Ameri
The definition of ManufacturingOrganization should be broad enough that it can be applied to a company like Toyota as well as a small family-run machine shop.
Hence the recommendation to make it a LocalBusiness subtype.
Hence the recommendation to make it a LocalBusiness subtype.
But a large company like Toyota wouldn't fall under LocalBusiness, would it?
@reidyoder it "could", depends on which legal entity your actually talking about when you say "Toyota". But your probably wanting schema:Organization
@reidyoder Thanks for getting this started. Have you thought about developing some definitions for "capability". The capability concept should be described at multiple levels: e.g. mfgProcessCapability and mfgOrganizationCapability would be defined quite differently. Not sure if there is an equivalent or starting point from schema.org but standard terminology here could be very helpful for CAx tool developers. Just a thought...
@wzbernstein I totally agree with you that "capability" is an important concept when describing a ManufacturingOrganization. But the problem is that "capability" has many dimensions and only the important ones can be included in mfg.schema.org. Basically, introducing new vocabulary should be justifiable exclusively in a "web search" use case. Perhaps "capability" can be represented indirectly through other terms such as "material" or "production volume" (as the properties of ManufacturingService). Or "QualityCertification" can be used as an indicator of "organizational capability". But more discussion is needed here ...
Quick update -- I've added two new properties to ManufacturingService:
I also created a VolumeLevel type, which is a subclass of enumeration and has the options of low, medium, and high. This was made for the range of the aforementioned productionVolume property.
New additions:
- Industry (subclass of Intangible): link
- anzsic (property of Industry): link
- gics (property of Industry): link
- icb (property of Industry): link
- nace (property of Industry): link
- sic (property of Industry): link
- sni (property of Industry): link
- trbc (property of Industry): link
- uksic (property of Industry): link
- hasProduct (property of ManufacturingOrganization): link
Are you aware of the fact that some properties for industry classifications do already exist, like
http://schema.org/isicV4
http://schema.org/naics
As for
hasProduct (property of ManufacturingOrganization): link
Are you aware of
http://schema.org/manufacturer
And how is a ManufacturingOrganization different from any other organisation? Do we need a subtype?
Also: How is your proposal related to the GS1 schema,
http://blog.schema.org/2016/02/gs1-milestone-first-schemaorg-external.html
?
Martin
martin hepp http://www.heppnetz.de [email protected] @mfhepp
On 19 Nov 2016, at 04:27, Reid Yoder [email protected] wrote:
New additions:
• Industry (subclass of Intangible): link • anzsic (property of Industry): link • gics (property of Industry): link • icb (property of Industry): link • nace (property of Industry): link • sic (property of Industry): link • sni (property of Industry): link • trbc (property of Industry): link • uksic (property of Industry): link • hasProduct (property of ManufacturingOrganization): link — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
@mfhepp Yes, those two industry classification codes already exist which is why I didn't redefine them. I simply added the new Industry class to their domain.
You may be right about hasProduct vs. manufacturer. Though, a manufacturing organization that has a product available may not neccessarily be the manufacturer of that specific product. hasProduct- "A product produced and/or made available by an organization."
As for Organization vs. ManufacturingOrganization - What exactly are the differences between a subtype and a type extension? A ManufacturingOrganization is definitely different from just a general Organization, as we've added several new properties already (which is more than some other already-existing Organizations, such as Corporation which only adds 1 new property).
Not sure what you're asking with GS1. Our's is aiming to be a hosted extension and is not related to the GS1 external.
While we certainly may add terms in the future to our extension, what exactly do we need to do at this point to get the current mfg terms officially merged with schema into a hosted extension?
You need to ideally define the schema.org configuration files that would be used to define the extension and submit a pull request to the schemaorg GitHub repository https://github.com/schemaorg/schemaorg.
In addition to the vocabulary definition you should also create some examples to demonstrate how they would be used.
You may find the following series of blog posts useful in describing the practicalities of the process: 1 http://dataliberate.com/2016/02/10/evolving-schema-org-in-practice-pt1-the-bits-and-pieces/ , 2 http://dataliberate.com/2016/02/25/evolving-schema-org-in-practice-pt2-working-within-the-vocabulary/, and 3 http://dataliberate.com/2016/03/01/evolving-schema-org-in-practice-pt3-choosing-where-to-extend/ .
~Richard.
Richard Wallis Founder, Data Liberate http://dataliberate.com Linkedin: http://www.linkedin.com/in/richardwallis Twitter: @rjw
On 30 November 2016 at 20:23, Reid Yoder [email protected] wrote:
While we certainly may add terms in the future to our extension, what exactly do we need to do at this point to get the current mfg terms officially merged with schema into a hosted extension?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/1421#issuecomment-263984501, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVdIGH537pPQANE2VbCE3NGa7-uV_pFks5rDdskgaJpZM4KkPp7 .
I've been looking thru for Pull Requests that have not received adequate review; #1452 seems to have no comments/discussion. Perhaps @RichardWallis, @mfhepp could be persuaded to take a look?
/cc @tmarshbing @rvguha @nicolastorzec @scor @vholland @tilid @chaals
@reidyoder I really don't like the use of 'hasProduct' and ideally would like to see that flipped to 'makesProduct'.
@mfhepp If they have mfgMaterials ... do we also have Commodities anywhere here ? I'd like to see it all the way through... so that we have a way to see relationships between Materials and Commodities and Products. Do we have those properties to tie it all together for manufactured goods ?
A couple of small suggestions:
- Rather than having Text as the range for
marketServed, can we use http://schema.org/Continent and maybe add http://schema.org/Country? - Rather than creating
mfgServiceProvided, should we create a genericserviceProvidedas a named reverse for the existing http://schema.org/provider?
-
If
marketServedbecame a sub-property of areaServed, we would get the range of possibilities you are looking for. -
I see the attraction for a generic
serviceProvidedproperty with a domain includes of Person & Organization and range of Service - providing a way to list the services that an organisation or person has capabilities for. Currently this relationship is handled via Offer, as in a Service offered by an organisation/person. The existence of the [reverse] provider property demonstrates that Offer is not always considered the most appropriate route. I would also say that serviceProvided and provider are a useful and acceptable reverse pair. -
I agree with @thadguidry that hasProduct is not a good name. My suggestion would be manufacturesProduct (a reverse property for manufacturer)
-
Thanks for the input. We will change hasProduct property to manufacturesProduct (which is inverse of manufacturer).
-
we can replace marketServed with areaServed (delete marketServed) because the intention of this property is to define the geographical areas a ManufacturingOrganization serves.
-
we will use a generic serviceProvided instead of mfgServiceProvided.
@reidyoder please apply the suggested changes.
/cc @RichardWallis @vholland @thadguidry
+1, areaServed seems much better
@RichardWallis @vholland @thadguidry @danbri I've updated the original post with the current terms.
- The 'marketServed' property has been removed (the core 'areaServed' property is sufficient).
- The 'hasProduct' property has been changed to 'manufacturesProduct', with domain 'Organization' and range 'Product'.
- The 'mfgServiceProvided' property has been changed to 'serviceProvided' with domain 'Organization' and 'Person' and range 'Service'.
I'm curious if the mfgMaterial property needs any changes?
Instead of ‘serviceProvided’ as a new property, the existing property ‘providesService’ can be used. The domain of this property needs to be modified to include ‘Organization’ or ‘Person’ . Using this property, organizations and persons can be directly linked to the services they provide. The alternative (indirect) method is to use OfferCatalog.
This issue is being tagged as Stale due to inactivity.
This issue is being tagged as Stale due to inactivity.
a new proposal will be posted soon. let's keep this issue active.
Would really support including Nace nomenclature as it is widely used in EU. And some EU countries use derivatives from Nace and not the isicV4 one.
Below are the proposed diagrams for manufacturing extension. Comments/feedback appreciated:

I'd like to receive some feedback on the proposed diagram (above) for manufacturing extension of schema.org.
This proposal has been stagnant since 2020. We would like to revisit it. It is basically the manufacturing extension of schema.org, and we would like to enable manufacturing companies to markup their website for better findability. Can someone suggest what the next step should be for us? @RichardWallis @vholland @thadguidry @danbri
This issue is being nudged due to inactivity.