[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: English Language Tags -- Stock vs. Inventory
Irvin Chmielewski wrote that "One of the main problems...with Natural Language is that [a] word can have multiple meanings. Take the word STOCK. - Something you buy on the NYSE or something you can buy at a cattle ranch or something you can buy at a gun store or something that you can buy to make soup." Multiple meanings are a concern for the folks who do things like the BSR Basic Semantics Register. Why don't we delegate that problem to them? For example, the list of BSR Semantic Components includes both terms as Specific Concepts (SC), though there's some question whether "Stock" should simply be made a deprecated synonym of the preferred "Inventory." The relevant BSR definitions are: ID 719 -- Inventory --- The complete list of items stored with their related quantities and/or value. Note: QUESTION Should Stock and Inventory be combined, with stock as a synonym of inventory as shown here? See also [718.] Synonym(s): Stock Context: Used generally with the exception of the US. ID 718 --- Stock --- A physical pile of goods ready for sale, distribution, use, etc. Note: Inventory is the preferred term.QUESTION Should this be combined with Inventory, with stock as a synonym of inventory? See also 719. The two definitions read differently to me, though they refer to one another: Stock is physical, while Inventory is virtual (a "list"). That may be a difference without a distinction since everything in an EDI or ebXML business document is "virtual," anyway. The BSR definition of "Stock," though, makes it clear that they're not talking about the NYSE or cattle. Note that the BSR defines a numeric Identification code accompanying each Semantic Component - e.g., 719 and 718 for Inventory and Stock, respectively. Semantic Units are supposed to be built up from these "smaller" Semantic Components to form names, like "Importer.Location.City.Name," and have numeric identification codes in their own right. If people are hung up on non-mnemonic UIDs, maybe the BSR numeric identification codes would work. UN/EDIFACT seems to prefer the word "Inventory" over "Stock" by 2:1 as used in boilerplate, definitions and descriptions. Sometimes UN/EDIFACT even uses the two terms interchangeably, as in the D01A INVRPT UNSM message: Segment group 12: NAD-LOC is "a segment group to identify the owner of the inventory," but the NAD group trigger segment is "A segment to identify the owner of the stock." Sandy Klausner notes that "a natural language mark-up tag cannot be modified once the semantic component is made public." That's true - the function or meaning of the concept "Stock" can't just be changed without screwing up the people who have been using that concept. But it's unlikely that English will evolve over the next century making the term completely erroneous or misleading. And if a better term, like Inventory, were devised, appropriate aliasing could be implemented with the old deprecated term gradually falling out of use. In the BSR, #718 could be made equivalent to, and interchangeable with, #719. Occasionally, you might end up with terms like "buyer" used ambiguously (is it a customer, or an employee who decides what apparel a retailer will stock?), but a good vetting process should avoid too many of these situations. At this point, I wish one of the BSR proponents would step in and tell us how they ensure consistency in the register. Sandy adds "if the semantic component had a base identity expression grounded in an immutable UID, then its owner could update the natural language expression without [affecting] third-party references." Why can't "Inventory" be just as immutable as UID 719? If the definition of "Inventory" has to be augmented or clarified, it can be done through the BSR registration process without affecting anybody who has been using "Inventory" as part of their tag names. William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
Powered by eList eXpress LLC