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

Protocol conversion to GS1-compatible supply chain data #105

Open
pospi opened this issue Dec 18, 2019 · 6 comments
Open

Protocol conversion to GS1-compatible supply chain data #105

pospi opened this issue Dec 18, 2019 · 6 comments
Labels
enhancement New feature or request Epic

Comments

@pospi
Copy link
Member

pospi commented Dec 18, 2019

High-level epic for collecting information on this protocol conversion; which would enable interoperability with global supply chains and many existing commercial ERP systems.

Industry case studies already in progress should see support for this module landing some time early 2020.

@pospi pospi added the enhancement New feature or request label Dec 18, 2019
@fosterlynn
Copy link

As input, here's the data elements that GoodRelations vocabulary has. I think GR was brought over to schema.org too, which is dominant in SEO I think, so the vocabulary naming may be somewhat standard in the semantic web, although I haven't really researched it. But we'd want to take requirements from whichever user group(s) want to use those identifiers, of course.

gr-gtin

@pospi
Copy link
Member Author

pospi commented Dec 27, 2019

Also just came across some of these goodies in what OriginTrail are doing: https://github.com/OriginTrail/ot-node/tree/d8ba15bcc76ef7be2c627a9c962047b815f65408/modules/transpiler/epcis

They're targeting GS1 EPCIS, GS1 CBV, and W3C WoT.

@pospi
Copy link
Member Author

pospi commented Jan 6, 2020

So I've been talking with @TheLaughableCoder and it turns out that GS1 have a number of commercial aspects to their system which basically make them impractical to a lot of industries and to any small enterprise.

It's particularly problematic in industries like building where there are intermediary supply chain participants who perform processing on less refined materials. E.g. you buy some steel, it comes in 12m lengths with a GS1 barcode provided by the producer. Now you cut it up into 1m lengths and want to sell it on- so you end up having to pay for 12 more barcodes just to do that. Then it might get galvanised or coated and thus needs another barcode.

So, lots of problems stemming from this extractive mentality. Thus, I'm putting this waay down the bottom of the "wants" list until such time as a commercial client feels it is necessary. It would be much better to devise our own barcoding system that uses an open standard for encoding Holochain identifiers, and perhaps provide some registration functionality to associate our IDs with GS1 IDs for systems which need to use them.

@fosterlynn
Copy link

it turns out that GS1 have a number of commercial aspects to their system which basically make them impractical to a lot of industries and to any small enterprise.

yeah, that's why it is not part of VF atm

Thus, I'm putting this waay down the bottom of the "wants" list until such time as a commercial client feels it is necessary.

👍 In my opinion, that should be true of everything that is not the very basic core spec. Let's do these kinds of things in partnership with user / dev teams that actively want to start using HoloREA.

@pospi
Copy link
Member Author

pospi commented Jan 8, 2020 via email

@fosterlynn
Copy link

Yes of course! That's why these tasks are here, only as placeholders.

Sorry, got it.

Maybe it's worth making a milestone for "proposed future work

Good idea, done.

@pospi pospi added the Epic label Jan 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Epic
Projects
None yet
Development

No branches or pull requests

2 participants