Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve expressivity for some specific common product variant attributes (size, pattern) #2587

Open
6 tasks
danbri opened this issue May 28, 2020 · 35 comments
Open
6 tasks
Assignees
Labels
no-issue-activity schema.org vocab General top level tag for issues on the vocabulary

Comments

@danbri
Copy link
Contributor

@danbri danbri commented May 28, 2020

Context - This is a proposal from Google (/cc @alex-jansen) based on our experience consuming schema.org Product markup and working with similar data from online merchants. If it were accepted, it would make it easier for us and others to understand a number of common situations via Schema.org.

See also #1797

Introduction

Many products on the web are variants of a “master” or “parent” product. Such variants typically only vary on common attributes such as size, color, gender, age group, and pattern. This is a proposal to add some additional supporting vocabulary in the area of size and pattern, building upon schema.org's existing structures. It is motivated by our experience cross-domain but is particularly concerned with filling expressivity gaps around description of apparel. See for example https://www.statista.com/study/38340/ecommerce-report-fashion/ as background for the scale of the fashion/apparel data in circulation.

For example, a T-shirt can be sold with the following variations:

  • color: blue, red, white
  • size: S, M, L, XL
  • size type (fit): regular, petite, oversize
  • pattern: solid, striped

A cell phone can be sold with the following variations:

  • color: space gray, midnight green, gold
  • size (memory): 64GB, 256GB, 512GB

A golf club can be sold with the following variations:

  • gender: male, female
  • age group: kids, adults
  • size: standard, +5 inch, -5 inch

When users search for different products across the web they often want to see these different variations of a product grouped together to understand what options are available to them. However, currently, Schema.org provides only a limited set of variant attributes, for example color, material, and intended age and gender. Although the PropertyValue construction, or non-schema.org properties in other namespaces, could both be used here, we see an opportunity to improve schema.org coverage for many cases by adding a small amount of vocabulary.

Proposal details

Our proposal is to increase support for a few common variant attributes. This is an initial sketch of a design for discussion, with various issues arising highlighted below.

Pattern

Add a text-valued /pattern property, analagous to https://schema.org/material

Size-related

Add a new class “SizeDetails” allowing merchants to express the size of their products.

Properties of this class could describe, for example:

  • The size of their product
  • The size system in which the size is given
  • A size type (in the sense of a named or coded size), for example regular, petite, oversize, maternity

Aside - there may be general improvements possible to allow the variant structure of product groups to be described more explicitly (e.g. groups of products that share common characteristics except for known varying attributes such as size, color). However the focus here is on the underlying descriptive attributes rather than capturing such grouping structures.

Scoping Questions

  • colloquially, we can speak of the "size" of an SD memory card both in terms of physical size, but also its storage capacity in digital terms (e.g. gigabytes). Similar issues arise with food (packaged/dry, with packaging included, cooked etc.). We should be clear whether a SizeDetails type is purely for physical size, and whether it is intended to be applicable for anything that has (some kind of) size, or focus on the ecommerce / product case. The type name might need adapting accordingly.
  • consider use of a subproperty hierarchy below /size to clarify which notion of size is being appealed to
  • explore patterns that use http://schema.org/QuantitativeValue + a /unitCode.
  • we should examine corner-cases that are close to online shopping but modeled differently in schema.org, specifically food-related (recipes, menus).
  • document relationships with existing /fileSize /servingSize /contentSize /floorSize properties, and the /QualitativeValue type.
  • consider whether this proposal would be improved if Product had subtypes for major categories such as a hypothetical ApparelProduct.

Schema

  • add a property, /pattern - values are Text or URL. "A pattern of something (product or creative work, ...) e.g. "floral", "geometric", "striped". Applicable to apparel products but also furniture, curtains.
    • while referencing patterns by URL may be overkill for most ecommerce scenarios, it is good to be consistent with the existing /material property, and there are various places where patterns are codified e.g. see those linked from https://www.wikidata.org/wiki/Q3421342
  • add a type, SizeDetails, definition "a StructuredValue describing the size-related properties of something, typically in the context of product offers for e-commerce."
  • add properties for SizeDetails
    • /apparelType - values from an enumeration or Text as fallback for others. Enumeration would encode (regular, petite, oversize, maternity) - enum value names to be decided
    • /apparelSizeSystem - values also enum + Text, with the enumeration handling (au, br, cn, de, eu, fr, it, jp, mex, uk, us). This would be applicable to apparel and to shoes.
    • /size - values are Text or QuantitativeValue or QualitativeValue. e.g. "2XL", "46". Applicable to Apparel but also memory storage, jewelry, shoes, prints, .... Potentially the super-property for more specific properties.
@danbri danbri self-assigned this May 28, 2020
@danbri danbri added the schema.org vocab General top level tag for issues on the vocabulary label May 28, 2020
@jvandriel
Copy link

@jvandriel jvandriel commented May 28, 2020

Sounds good to me, though I wonder whether it might be an idea to take GS1's Web Vocabulary into account for this expansion. After all, they already did a lot of work in regards to apparel and consumable products and I wouldn't like us to try to reinvent the wheel (seems to me you already had a peek at it though).

@jvandriel
Copy link

@jvandriel jvandriel commented May 29, 2020

Aside - there may be general improvements possible to allow the variant structure of product groups to be described more explicitly (e.g. groups of products that share common characteristics except for known varying attributes such as size, color). However the focus here is on the underlying descriptive attributes rather than capturing such grouping structures.

#1797 was opened to try to find a solution for this (just a reference).

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 2, 2020

Hey Jarno, thanks for the comments. We should have a concrete proposal related to #1797 soon. Regarding GS1, both @alex-jansen and myself have been in touch with GS1 (via @philarcher). We would like a solution that is fully part of schema.org but mappings or shared definitions here could well be possible.

Considering the scoping questions above, at GS1 their https://www.gs1.org/voc/SizeDetails is currently oriented to wearables. We need to decide how much "size" description we can sensibly do here with a single structure, i.e. non-wearables (for sale or in other situations too).

@philarcher
Copy link

@philarcher philarcher commented Jun 2, 2020

Just to acknowledge this thread which is important to us at GS1. I'll schedule some time to look at it with colleagues - we want to help!

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 2, 2020

For named sizes ... @alex-jansen and I are just discussing whether a property /sizeSystem and a /SizeSystemEnumeration sort of a structure (with subtyping...) could accommodate other domains that have formal sizes, e.g. screws, wedding rings, electronics e.g. ram chips, perfume, mobile phone storage; in addition to apparel (which itself has different kinds of named size e.g. bra sizes).

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 2, 2020

To work through the bra size example, the current sketch of a schema above doesn't list sizing systems at the same granularity made possible in GS1 (https://www.gs1.org/voc/SizeTypeCode); maybe we should.

@jvandriel
Copy link

@jvandriel jvandriel commented Jun 2, 2020

Question: Do we really need to add such granularity to schema.org or does it suffice to add properties and classes which enable people to refer to external vocabularies like GS1's?

From a publisher perspective it's definitely easier if one doesn't have to go through other vocabularies yet at the same time we run the risk of having to add a lot of types and properties that might be very domain and/or product type specific.

@jdevalk
Copy link
Contributor

@jdevalk jdevalk commented Jun 5, 2020

Hi! Excited to see this!

Can I ask that as we tackle this, we also take into account how the different product / parameter variant URLs are related to each other? So a way to attach URLs to each of these parameters would be appreciated.

@philarcher
Copy link

@philarcher philarcher commented Jun 5, 2020

@jdevalk - GS1 has a whole standard for how to put not just GTINs but batch/lot numbers, serial numbers, product variants, expiry dates and more into URLs - and I'm going to be seriously upset if schema.org proposes a different structure! Standard and supporting material at https://www.gs1.org/standards/gs1-digital-link, code and more at github.com/gs1

@jdevalk
Copy link
Contributor

@jdevalk jdevalk commented Jun 5, 2020

@philarcher I'm aware of those standards but I'm afraid they're going about it a bit the wrong way as far as I can tell. I'm thinking about existing eCommerce sites, where we already have URLs for different product variants and we need to be able to make their relation to each other clear in Schema. At that point, changing the URLs to other structures is unfortunately not an option.

BTW this doesn't mean we couldn't make those URLs available as "entry points" that redirect to the correct URL in the system as soon as we have that data somewhere. So a URL like /gtin/01234567890128/lot/ABC123/ could redirect to the correct product / variant page.

@philarcher
Copy link

@philarcher philarcher commented Jun 5, 2020

Certainly not asking anyone to re-eningeer their sites, no. As you say, @jdevalk - just redirect from the structured URL to... I don't care what. And those redirects can be updated at any time of course so you have a persistent URL for the product. And then we can get into resolvers with associated linksets to point to related things like instruction manuals, nutritional info, recycling info, recall status APIs and more. Anyway... this probably isn't the place to talk about that. I have other issues I need to talk about in the context of schema.org but I'll stop typing now.

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 5, 2020

I think schema.org is at least missing a very basic text field for /size, analogous to /color /material and (proposed here) /pattern. That should be easy to do and I would like to proceed with that without getting bogged down.

And then...

I would like to go deeper and have a structured way to represent external size systems / named sizes etc. Looking at https://www.gs1.org/voc/SizeDetails it is very heavily wearable/apparel oriented. Schema.org also has existing /width, /height, /depth /weight to consider. Clothing is both important but somewhat different to other things that have sizes, because clothes are floppy and you're talking about the size of the wearer implicitly. We should figure out a solid way of describing clothes, but not limit things needlessly to just clothes.

If you look at what Google Shopping have in their feed system (/cc @alex-jansen who I'm channeling for here but who should speak his mind directly!), there is

  • a size attribute, a singular non-repeating field, for anything that has a size on some standardized system --- not limited to apparel, also jewelery, perfume, etc etc
  • alongside this, they also have sizeType, and sizeSystem, which are both apparel-centric (both enums)
  • the proposal above tries to generalize these

If we could find a design that takes as inputs:

  • schema.org's existing terms
  • gs1's design
  • google shopping
  • anything else folk suggest

... that would be ideal!

@alex-jansen
Copy link
Contributor

@alex-jansen alex-jansen commented Jun 8, 2020

Very much in favor of quickly adding /size and /pattern as text fields since:

  1. both are important for consumers and are among the most frequently submitted fields in shopping feeds.
  2. These fields are used for many more product categories than just Apparel, so a free-form text field makes sense (consistent with /color and /material).
  3. /size (together with /color) is very important for expressing Product variants.

Specifically for Apparel I am happy to further explore using or expanding on GS1 WearableProduct with more structured representations of size types, size systems, and color systems.

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 9, 2020

ping @tmarshbing - any thoughts?

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 9, 2020

As context (for everyone), e.g. see https://www.blog.google/products/shopping/its-now-free-to-sell-on-google/+ Bing have Shopping feeds based on the Google Shopping feed specs, e.g. see https://help.ads.microsoft.com/#apex/3/en/51084/1 (Bing) and https://support.google.com/merchants/answer/7052112?hl=en (Google Product data specification).

At Google we are making a series of Schema.org proposals in this area to bring Schema.org for e-commerce closer to parity to the kinds of shopping feeds that Google and Bing have been using, for example the suggestions above and the /ProductGroup discussion in #1797.

/cc @philarcher @mfhepp

Edit: see also https://developers.facebook.com/docs/marketing-api/catalog/reference/#da-commerce from Facebook, which again adopts the same design, for size, pattern etc.

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 9, 2020

Here are strawman definitions for textually oriented /pattern and /size properties. For now I've stopped short of all the additional structure around named size systems, SizeDetails, etc.

Comments?

:material a rdf:Property ;
    rdfs:label "pattern" ;

    :isPartOf <http://pending.schema.org> ;
    :source <https://github.com/schemaorg/schemaorg/issues/1797> ;
    :category "issue-1797" ;

    :domainIncludes :CreativeWork, :Product ;
    :rangeIncludes :Text, :DefinedTerm ;

    rdfs:comment "A pattern that something has, for example 'polka dot', 'striped', 
        'Canadian flag'. Values are typically expressed as text, although links 
        to controlled value schemes are also supported." 

:size a rdf:Property; 
    rdfs:label "size" ;
    :isPartOf <http://pending.schema.org> ;
    :source <https://github.com/schemaorg/schemaorg/issues/1797> ;
    :category "issue-1797" ;

    :domainIncludes :CreativeWork, :Product ;
    :rangeIncludes :Text, :QuantitativeValue, :DefinedTerm;

     rdfs:comment "A standardized size of a product or creative work, often simplifying richer 
         information into a simple textual string, either through referring to named sizes or (in the
         case of product markup), by adopting conventional simplifications. Use of QuantitativeValue 
         with a unitCode or unitText can add more structure; in other cases, the /width, /height, 
         /depth and /weight properties may be more applicable. ".

@mgh128
Copy link

@mgh128 mgh128 commented Jun 9, 2020

I definitely support the idea of defining sub-properties that have more precise definition.

It's why the GS1 Web vocabulary defines separate properties such as gs1:grossWeight, gs1:netWeight and gs1:drainedWeight , which are all logically sub-properties of schema:weight
For a jar of pickled onions, the consumer is probably most interested in the drained weight (of the onions) than the net weight (of the onions and vinegar) or gross weight (also including the glass jar).

For linear dimensions we distinguish between the boxed dimensions (e.g. gs1:inPackageDepth, gs1:inPackageHeight, gs1:inPackageWidth, gs1:inPackageDiameter) as well as the unboxed dimensions of the actual product (e.g. gs1:outOfPackageDepth, gs1:outOfPackageHeight, gs1:outOfPackageWidth, gs1:outOfPackageDiameter ).

Even those might not be sufficient to characterise some products. If you think of a lens for a DSLR camera, you might be even more interested in knowing the focal length (which may be a single value or a range, for a zoom lens). You probably also need to know the filter diameter.

For 'size' (memory capacity) of a memory card, hard disk or solid state drive, we don't yet have a specific property, though we do define gs1:referencedFileSize to express the size of a media file or document.

For some wearable products, a single size code might suffice, indicating small, medium, large, extra large etc. For others, such as trousers, we typically need to know the waist measurement quantitatively and the inside leg measurement either quantitatively or qualitatively (regular, short or long)

I've attached a diagram to show some of the GS1 size properties, particularly as they relate to gs1:WearableProduct . Not shown are the boxed / unboxed dimensions mentioned above or the various subproperties of weight.

GS1-size-properties-WearableProduct.pdf

I'm very supportive of schema.org 'importing' terms and definitions from the GS1 Web vocabulary to make it easier to express details more precisely.

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 9, 2020

Thanks @mgh128, that is very useful!

I was thrown a bit because GS1's wearable-specific size modeling is in a more generally named type, "SizeDetails" rather than e.g. WearableSizeDetails. @philarcher mentioned too that food sizing is handled elsewhere, via netContent property. I have been wondering how much work we can get a single cross-domain SizeDetails-style type to do, e.g. by attaching domain-oriented properties to it.

A lot of this sort of data seems to flow around currently in purely textual form currently, but as soon as you start to have additional information in a nearby field (e.g. size systems and other qualifiers) there's a natural need to group them via a type, otherwise you can't group them together if two or more "sizes" are usefully ascribed to the same entity. I'd like to see if we can make a more general SizeDetails type for Schema.org that supports also the precise codes for wearables that you have in GS1's SizeDetails.

@mgh128
Copy link

@mgh128 mgh128 commented Jun 9, 2020

For all products in general, we can use the following properties:
https://www.gs1.org/voc/netContent (can express a mass ('weight') or volume)
https://www.gs1.org/voc/netWeight
https://www.gs1.org/voc/grossWeight

https://www.gs1.org/voc/drainedWeight is defined for gs1:FoodBeverageTobaccoProduct

Within gs1:Clothing (a subclass of gs1:WearableProduct), the property gs1:textileMaterial links to the gs1:TextileMaterialDetails class which defines further properties such as:
https://www.gs1.org/voc/textileMaterialThreadCount
https://www.gs1.org/voc/textileMaterialWeight

(which may be relevant for expressing the thickness / weight per unit area of clothing or fabric used in other products such as tents, rucksacks, etc.). For technical fabrics for outdoor clothing, e.g. for waterproof jackets etc., it is quite usual to see the thickness or mass per unit area of the fabric expressed in denier and/or grams per square metre.

You've probably already realised that gs1:SizeDetails is intended as a repeatable class, so a particular wearable product might use gs1:size to connect to a list of elements of rdf:type gs1:SizeDetails, so that one element in the list can express a quantitative value for waist measurement and another element in the list can express a quantitative value for inseam / inside leg, etc.

gs1:SizeDetails is also intended to be sufficiently flexible to express shoe sizes, e.g. as both a UK men's size 9.5 and a European men's size 44.

For anything that is not really a physical / spatial dimension, then it might be a good idea to use a precise name for the subproperty, even if we ultimately declare it to be a subproperty of a generic size property. For example, we might define that schema:memoryCapacity is a subproperty of some generic schema:size property (as a way of discovering various kinds of non-spatial 'size' properties) - and use the rdfs:domain / schema:domainIncludes to attach such properties to subclasses of schema:Product

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 9, 2020

Thanks @mgh128 - we are thinking along similar lines; both w.r.t. using sub-properties, and on the useful repeatability of a SizeDetails-like type, and on keeping things scoped to physical/spatial (e.g. deal explicitly with memory card case, as you say).

There are other things that have physical sizes in schema.org such as foods (recipes, menus) and real estate. Not clear to me yet if those can be sensibly handled in a single SizeDetails type

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 9, 2020

btw notes towards definitions for pending.schema.org on this issue and the related ProductGroup / variants discussion are here:

https://docs.google.com/document/d/19DpcLStce-n1iF1rsIyS3Pz9_h-xSaQ1J_Nu7m24Wjo/edit#

(using schema.org's newly adopted mcf-flavoured-turtle definition format)

@jvandriel
Copy link

@jvandriel jvandriel commented Jun 16, 2020

I've created an overview of what Google, Bing and Facebook specifications have to say about some of the properties we've been discussing here (skipped Amazon as it has too many different attribute specifications for different categories). By the looks of it IMHO it seems quite doable to come up with a finalized structure that pretty much aligns with what their feed systems require.

The benefit of doing so is that we might expect a good amount of such structured data actually getting published as it represents data many publishers already have available.

I haven't looked into how this type of data should be expressed with help of GS1's web vocabulary yet nor how to match this with feed specifications of Google, Bing and Facebook, that'll be up next.

Summary:

  • Product
    • item_group_id
      • Google, Bing & Facebook expect a Text value
    • product_type
      • Google, Bing & Facebook expect the item’s taxonomy value (string) specific to the site/domain
    • google_product_category / product_category
      • Google, Bing & Facebook expect the item’s taxonomy value (string) specific to Google’s product taxonomy
    • pattern
      • Google, Bing & Facebook expect a Text value
      • Google, Bing & Facebook all accept the pattern property as an optional value without any category limitations
    • size
      • Google, Bing & Facebook expect a Text value
      • Google & Bing only accept the size property for items in apparel categories (Google’s product taxonomy)
      • Facebook accepts the pattern property without any category limitations
    • size_type
      • Google & Bing expect Enumeration values
      • Google & Bing only accept the size_type property for items in apparel categories (Google’s product taxonomy)
      • Facebook has no size_type property. Their documentation gives the impression it should be expressed as part of the size property's value
    • size_system / override
      • Google & Bing and Facebook expect Enumerated values (limited lists of ISO 3166-1 (ISO 3166-1 alpha-2) or ISO 3166-2 codes)
      • Google & Bing only accept the size_system property for items in apparel categories (Google’s product taxonomy)
      • Facebook accepts the override property without any category limitations

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 19, 2020

@jvandriel - thanks - that it is super useful! and fits with what I know. @alex-jansen might have some comments on the details but this I think shows that there's a piece of useful work to do here.

@alex-jansen
Copy link
Contributor

@alex-jansen alex-jansen commented Jun 19, 2020

@jvandriel thank you for the comparison! small comment:

@jvandriel
Copy link

@jvandriel jvandriel commented Jun 19, 2020

You're welcome @danbri , and just for awareness, there are still some other attributes left but given those were out of scope for this issue I didn't include them in the overview. If you'd like those added, just let me know.

Based on https://support.google.com/merchants/answer/7052112?hl=en I understood things differently ever so slightly. Thanks for the additional info @alex-jansen, I've updated the summary to reflect this (also double checked Bing and Facebook).

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 22, 2020

For this issue and #1797 -

This is a work in progress, but I expect to include it in the 9.0 release as a Pending change.

@mgh128
Copy link

@mgh128 mgh128 commented Jun 22, 2020

Just to let you all know that I've extended Jarno's spreadsheet at https://docs.google.com/spreadsheets/d/1ArqPqxIpw7O4aqRWgkJ43lLxmjSSeBPitfV7l83OXBg/edit?usp=sharing to also include mappings to the corresponding terms in the GS1 Web vocabulary.

Regarding https://webschemas.org/ProductGroup , I'd also point out that GS1 has a Global Model Number for identifying product groupings at a level above the GTIN. More info on that at https://www.gs1.org/sites/default/files/docs/idkeys/gs1_gmn_executive_summary.pdf and in the GS1 General Specifications - see section 2.6.13 of https://www.gs1.org/sites/default/files/docs/barcodes/GS1_General_Specifications.pdf

@danbri
Copy link
Contributor Author

@danbri danbri commented Jun 25, 2020

@mgh128 thanks! is there a property in GS1 Web vocab for the Global Model Number for product groupings? Do any of the gs1-related schema.org properties already cover it?

@mgh128
Copy link

@mgh128 mgh128 commented Jun 25, 2020

@danbri - unfortunately it's not yet in the GS1 Web vocabulary.

We did make some recent updates but appear to have overlooked adding missing properties that link to each of our primary GS1 identification keys (the equivalent of gs1:gtin / schema:gtin for our other identifiers such as SSCC, GRAI, GIAI, etc., including Global Model Number (GMN). We would probably also need to add some extra classes where appropriate.

Looking at schema.org, https://schema.org/ProductModel would appear to be the correct class. I see that there is a property https://schema.org/model which connects a https://schema.org/Product to a https://schema.org/ProductModel

However, I think that within https://schema.org/ProductModel we'd still need a dedicated property (e.g. https://schema.org/globalModelNumber ) to express the GS1 Global Model Number identifier of the https://schema.org/ProductModel class, in the same way that we have the https://schema.org/gtin property defined within https://schema.org/Product to express the GS1 Global Trade Item Number (GTIN) identifier of the product.

As triples, I'm expecting to be able to write something like this:

_:1 rdf:type https://schema.org/Product .
_:1 https://schema.org/gtin "00614141123452" .

_:1 https://schema.org/model _:2 .

_:2 rdf:type https://schema.org/ProductModel .
_:2 https://schema.org/globalModelNumber "0614141ABC987654321XYZ" .

I would not recommend overloading https://schema.org/model to express the GS1 Global Model Number identifier - even though I see that its range can be https://schema.org/Text as well as https://schema.org/ProductModel . I hope that the triples above make the case for a dedicated property for globalModelNumber.

We will soon have an opportunity to make some further updates to the GS1 Web vocabulary and I'm aware that @philarcher is aware of some gaps or potential improvements in our semantics chapter for GS1 Digital Link, so we'll probably identify the necessary updates within that work, which is currently underway, though in principle the update to the GS1 Web vocabulary could even happen before v1.2 of GS1 Digital Link is ratified, since it's a separate work request.

@danbri
Copy link
Contributor Author

@danbri danbri commented Aug 25, 2020

The main changes here were added in version 9.0 (/pattern, /size), but we should continue looking into /SizeDetails

@schemaorg schemaorg deleted a comment from github-actions bot Aug 25, 2020
@github-actions
Copy link

@github-actions github-actions bot commented Oct 25, 2020

This issue is being tagged as Stale due to inactivity.

@danbri
Copy link
Contributor Author

@danbri danbri commented Nov 17, 2020

Coming back to this, filing some related links to find later:

Let's open up a fresh issue for continuing discussion on size (and related - width, height etc., named sized, measures etc.)

@mgh128
Copy link

@mgh128 mgh128 commented Nov 17, 2020

We're still interested in this discussion from the GS1 perspective.

We've developed a unit converter for Rec 20 unit codes ( https://github.com/gs1/UnitConverterUNECERec20 / https://gs1.github.io/UnitConverterUNECERec20/ ) to support situations where the data might be expressed using one UoM code (e.g. CEL for degrees Celsius) but the query expresses a different but interconvertible unit (e.g. FAH for degrees Fahrenheit). We're now also looking into extending this to provide cross-references across UN ECE Rec20, some GS1-internal UoM codes (used to temporarily fill some gaps) and also to cross-reference to UCUM and QUDT.

Our source code needs some minor modification to decouple the JSON data table from the JavaScript at https://gs1.github.io/UnitConverterUNECERec20/js/UnitConverterUNECERec20.js to make the JSON data table more accessible / reusable by other scripts and other programming languages.

@mgh128
Copy link

@mgh128 mgh128 commented Nov 17, 2020

... and regarding the earlier discussion about Global Model Number (GMN), we're expecting to update the GS1 Web vocabulary soon with a number of additional properties including some relating to GMN as well as filling in some other gaps.

Relating to units of measure, we're also likely to add a code list for various types of measurement - and cross-reference to QUDT 2.0 where appropriate.

@github-actions
Copy link

@github-actions github-actions bot commented Jan 17, 2021

This issue is being tagged as Stale due to inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-issue-activity schema.org vocab General top level tag for issues on the vocabulary
Projects
None yet
Development

No branches or pull requests

6 participants