CertificationDetails

[mgh128]

WR 21-000111 proposes some additional properties for gs1:CertificationDetails to make it more useful, so that an EPCIS event can reference online machine-interpretable details about a certification held by a product.

However, we might also want to be able to point to certification details for a location or organisation, so we might consider adjusting WR 21-000111 to broaden the definition of gs1:certificationValue so that it can apply to organisations and locations as well as products. We'd also need to broaden the rdfs:domain of gs1:certification so that it's no longer limited to a gs1:Product having a certification; a gs1:Place or gs1:Organization could also have certification details.

[VladimirAlexiev]

• draft: https://milecastle.media/dev2021/voc_epcis_extras/CertificationDetails
• IMHO certificationInfo should be merged to certification, see certification CertificationDetails vs certificationInfo DigitalLink  WebVoc#20. The shorter name is better, and "Info" is a parasitic word
• Someone also asked for certificationType (AnyURI), eg <organicFood>.
• @nikolatulechki would you need anything else for the Food Safety Market project?

[VladimirAlexiev]

gs1/WebVoc#20

[VladimirAlexiev]

EPCISEvent->certificationDetails is not a certification of the Event, but of some of the things mentioned in the event. Check CertificationDetails.certificationSubject to figure out which things it applies to.

This introduces additional field dependencies, in the form of a property chain:

• event.certificationDetails.cert.certificationSubject.subj means that subj is either event.readPoint|bizLocation|epcList|..., with the complication that the certificate may be for a "broader" place, whereas the event may mention a sub-place thereof

[VladimirAlexiev]

From today's meeting:

• declare that <object> -> gs1:certification -> CertificationDetails -> gs1:certificationSubject -> <object> are inverses
• draw a diagram showing <event> -> gs1:certificationInfo -> CertificationDetails -> gs1:certificationSubject -> <object> where <object> is any of the objects mentioned in the <event> because it's easy to be confused by gs1:certification vs gs1:certificationInformation (as I was)

More considerations:

• Maybe we should not use gs1:certificationInfo for <event> -> gs1:certificationInfo -> CertificationDetails because it's currently defined in WebVoc is a digital link from product to its certification?
  Maybe let's use epcis:certificationInfo (different namespace) or even epcis:applicableCertification (also different prop name)?
• certification CertificationDetails vs certificationInfo DigitalLink  WebVoc#20 raises the question that the exact same certificate may be available in different formats (HTML, PDF, JSONLD, Turtle, etc) so gs1:certification and gs1:certificationInfo (as currently defined in WebVoc) should be merged

[mgh128]

I thought we agreed to use gs1:certification within an EPCIS event to point to gs1:CertificationDetails but to broaden the rdfs:domain to support gs1:Product, gs1:Place and gs1:Organization

At least that was the basis for updating the preview at https://milecastle.media/dev2021/voc_epcis_extras/certification

[VladimirAlexiev]

@mgh128 I much prefer to merge gs1:certification and gs1:certificationInfo so I agree with you.

BTW, is it too late to simplify the class name gs1:CertificationDetails -> gs1:Certification ?

How do you like this diagram:

I know, it's too curvy, but are the arrows right? You can edit there.

declare that <object> -> gs1:certification -> CertificationDetails -> gs1:certificationSubject -> <object> are inverses

Correction: IF <cert> gs1:certificationSubject <obj> THEN <obj> gs1:certification <cert> but not vice versa, so the two props are partial inverses.

[mgh128]

I think it's probably far too late to rename gs1:CertificationDetails to gs1:Certification I also have doubts that we will merge gs1:certification and gs1:certificationInfo - but please discuss with Phil Archer. The diagram is good and I understand what it's expressing about gs1:certification and gs1:certificationSubject being partial inverse properties because an EPCIS event is generally not the gs1:certificationSubject of the gs1:CertificationDetails even though an EPCIS event may link via gs1:certification to gs1:CertificationDetails. No objection to the curves - but an epcis:bizLocation points to a gs1:Place, not to a gs1:Organization. We might have discussed this already once or twice ;-) source/destination point to a gs1:Organization Not sure that we can formally declare partial inverse properties in RDFS or OWL.

…

On Wed, Apr 28, 2021 at 3:30 PM Vladimir Alexiev ***@***.***> wrote: I much prefer to merge gs1:certification and gs1:certificationInfo so I agree with you. BTW, is it too late to simplify the class name gs1:CertificationDetails -> gs1:Certification ? How do you like this diagram <http://www.plantuml.com/plantuml/uml/ZOz1Qm8n48Nlyok6lUz1ZqifWlLG42hu2xApKvsItKXcKgY_lbXiM6cgEMRU-_BUMwcvQ6dqS9I1aSUJVQ4pYz8dOvrVHxPZ6AudaaYU0SWxLLnpD7aNSYPXUc5pudM1Jh4vwA8hgSqTSbb5liM3c-Jy8sLWVlmrxc8O4bdsNDyDm6QtVjrlFdaoRDldVrPqU85ehjM0onhmPaE7lPoteUZC8pha4sr53Q5Sj_3jdnhxr7ym6PHxtyRLmJd-gMqVnfTpB-YzN80LJqCQ_JS0> : <https://camo.githubusercontent.com/e1716139e762e1b801fc7b4bab638e59073bbcb2eabf02d892cd385541ace904/687474703a2f2f7777772e706c616e74756d6c2e636f6d2f706c616e74756d6c2f706e672f5a4f7a31516d386e34384e6c796f6b366c557a315a716966576c4c4734326875327841704b767349744b58634b67595f6c6258694d366367454d52552d5f42554d77637651366471533949316153554a56513470597a38644f7672564878505a3641756461615955305357784c4c6e704437614e535950585563357075644d314a6834767741386867537154536262356c694d33632d4a7938734c57566c6d727863384f346264734e4479446d365174566a726c4664616f52446c645672507155383565686a4d306f6e686d506145376c506f7465555a433870686134737235335135536a5f336a646e68787237796d365048787479524c6d4a642d674d71566e665470422d597a4e38304c4a7143515f4a5330> I know, it's too curvy, but are the arrows right? You can edit there. declare that -> gs1:certification -> CertificationDetails -> gs1:certificationSubject -> are inverses Correction: if <cert> gs1:certificationSubject <obj> then <obj> gs1:certification <cert> but not vice versa, so the two props are partial inverses. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#245 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSXRL42BXR2TKRLGQ4MWSLTLALZ7ANCNFSM423IP7SA> .

[VladimirAlexiev]

merge gs1:certification and gs1:certificationInfo

gs1/WebVoc#20

Diagram: Edited as EPCIS\Diagrams\certification-diagram.puml in #270 (sorry about the silly standard names):

Not sure that we can formally declare partial inverse properties in RDFS or OWL.

Not sure either, but we should state it in the text.

[VladimirAlexiev]

The above diagram is included in chapter "EPCIS Semantics".

[VladimirAlexiev]

@mgh128

As part of the FSM project (Food Safety Market), we're trying to map FSSC 22000 certs. Here are two sample records (org data skipped for brevity). FCC means "food chain category" and is described in FSSC-22000-Scheme-Version-5.1, p10, table1, cols Category/Subcategory (maps to certificationType).

FCC	Statement	Status	Initial certification	Date decision	Date issue	Date valid
CIV, I	Production of carbonated beverage, bottled water for drinking...	Valid	2010/08/06	2020/08/24	2020/08/25	2022/05/23
I	Processing of wood pulp to produce coated or uncoated paperboard...	Suspended	2015/05/16	2018/05/22	2018/05/22	2021/05/28

I don't know where the dates are defined, but you can see the logic from their chronology. We've mapped them as follows, please confirm:

• Initial certification: TODO, see below
• Date decision: gs1:certificationAuditDate
• Date issue: gs1:certificationStartDate
• Date valid: gs1:certificationEndDate

Need new fields:

• gs1:initialCertificationDate, xsd:date, "Date the certification was originally issued. May differ from the certificationStartDate of the current recertification cycle."
• gs1:certificationStatus, xsd:string, "Current status of the certification, eg valid, suspended, invalid"
• gs1:certificationStatement, rdf:langString, "Certification scope statement of the individual certification instance. The same certificationStandard can be concretized as (issued with) different certificationStatements in different instances."

Changes:

• gs1:certificationType: allow multiple values. Eg above you see that CIV and I are compatible and used together (CIV : Processing of ambient stable products, I : Production of food packaging and packaging materials)
• why gs1:certificationAgency (text) vs gs1:certificationAgencyURL? Isn't it better to have one object prop gs1:certificationAgency to point to a gs1:Organization node, which will have organizationName but can have many other properties?
• as decided on 7 Jun 2021 telco:
  • split certificationSubject to 3 optional multivalued fields eg named and described as
    • certifiedOrganization, gs1:Organization, "Organization(s) that the certification applies to"
    • certifiedPlace, gs1:Place, "Place(s) or plants/processing facilities that the certification applies to"
    • certifiedProduct, gs1:Product or gs1:IndividualProduct, "Product model(s) or individual (serialized) product(s) that the certification applies to"
  • describe the following logic in the class: "The certification applies to any of the listed Organizations to handle any of the listed Products at any of the listed Places (disjunction of the multiple values). It applies only to the listed combinations of Organizations, Products and Places (conjunction of the 3 fields), but any of them can be omitted depending on the nature of the certification."

Clarifications:

• clarify gs1:certificationStartDate as "Starting date of validity of the certification: original or in the current recertification cycle."
• clarify about gs1:certificationURI: is that of the particular certificate instance (corresponding to certificationIdentification) or of the kind of certificate (corresponding to certificationStandard)

[mgh128]

Hi @VladimirAlexiev

Thanks for this. You're correct about:

Date decision: gs1:certificationAuditDate
Date issue (start): gs1:certificationStartDate
Date valid (until): gs1:certificationEndDate

We can certainly consider including:

• gs1:initialCertificationDate, xsd:date, "Date the certification was originally issued. May differ from the certificationStartDate of the current recertification cycle."
• gs1:certificationStatus, xsd:string, "Current status of the certification, eg valid, suspended, invalid"
• gs1:certificationStatement, rdf:langString, "Certification scope statement of the individual certification instance. The same certificationStandard can be concretized as (issued with) different certificationStatements in different instances."

I assume that gs1:certificationType already permits multiple values; we don't enforce a cardinality constraint on that currently within the GS1 Web vocabulary, nor do we assert that it's a functional property, as far as I remember.

Why gs1:certificationAgency (text) vs gs1:certificationAgencyURL ? Isn't it better to have one object prop gs1:certificationAgency to point to a gs1:Organization node, which will have gs1:organizationName but can have many other properties?

Well, if the whole world were already using Linked Data, then of course you'd be right - and maybe we should be designing for that future state. However, currently it isn't and many existing paper / PDF certificates might currently only state the name of the certification agency. Adding gs1:certificationAgencyURL (a suggestion by Kevin Dean) at least provides for global disambiguation if multiple countries each have their own 'Food Standards Agency' or whatever. From an ontology / inference perspective, yes you're right that we can infer that the agency identified by that URL is a gs1:Organization or schema:Organization. It's the same dual-documentation issue we've been discussing for several weeks/months - are we trying to provide online definitions that explain syntactically how to populate fields correctly - or are we primarily catering for what is probably a relative minority interest of being able to infer that the agency is an Organization?

With your proposed approach, we'd at least need to provide guidance understandable for anyone about how to express the name of the agency even in situations where the agency does not yet publish Linked Data. However, it also might not be obvious to someone other than the agency whether they're using their website URL as their Linked Data URI to identify themselves or whether they're using a different URI for that purpose, considering the infamous HTTP Range-14 conundrum.

I agree that we still need to split certificationSubject to 3 optional multivalued fields e.g. named and described as

• certifiedOrganization, gs1:Organization, "Organization(s) that the certification applies to"
• certifiedPlace, gs1:Place, "Place(s) or plants/processing facilities that the certification applies to"
• certifiedProduct, gs1:Product or gs1:IndividualProduct, "Product model(s) or individual (serialized) product(s) that the certification applies to"

Thanks for the suggested clarifications. I'll try to make most of these edits to the preview files during my train journey tomorrow.

[VladimirAlexiev]

Well, if the whole world were already using Linked Data, then of course you'd be right - and maybe we should be designing for that future state.

If we don't design for that future state, we'll never reach it.

even in situations where the agency does not yet publish Linked Data

You described the biggest chicken and egg problem ever. With such approach we'll never beat negative network effects.
We can't afford to WAIT for every institution to make LOD about itself.
The fact is that very often OTHERS publish LOD about institutions, their departments, datasets, etc.

a relative minority interest of being able to infer that the agency is an Organization?

It's not about inference nor about minorities, but about proper data structuring.
If GS1 Voc wants to to Linked Data, it should do it right (cc @philarcher).

The current approach FORCES us into data consistency problems:

<my-cert>
  certificationAgencyURL <https://www.efsa.europa.eu>;
  certificationAgency "EFSA Ltd, owned by My Corp".

<your-cert>
  certificationAgencyURL <https://www.efsa.europa.eu>;
  certificationAgency "EFSA NGO, founded by me".

Now what's the proper name of https://www.efsa.europa.eu? Where is the master data about it?

are we trying to provide online definitions that explain syntactically how to populate fields correctly

We are not! An ontology describes the domain of discourse (part of the world), not a particular IT view on it. If you merely want to explain syntax, don't use semantic technologies.

However, currently it isn't and many existing paper / PDF certificates might currently only state the name of the certification agency.

That excel does not state anywhere that FSSC 22000 is the certification authority. But it's easy to figure out and RDFize their data as we did: it's a few fixed triples for 10k excel rows.

Similarly, if you process PDF certs, IMHO it's up to you to reconcile the cert authorities to some resources and thus help build up LOD. There cannot be millions of cert agencies, right?
Eg starting from US FDA https://www.wikidata.org/wiki/Q204711 I find it's a food safety organization https://www.wikidata.org/wiki/Q30234158 and https://w.wiki/3XgA finds 60 such world-wide

But you have a point, so to avoid the gs1/WebVoc#24 dichotomy I propose this:

---

• gs1:certificationAgencyName, rdf:langString, "Name of the organization issuing the certification standard or other requirement being met. Use this only if you don't have enough data to create certificationAgency as Organization."
• gs1:certificationAgency, gs1:Organization, "Organization issuing the certification standard or other requirement being met."

Currently I have to write

<certificate/(ROWNO)> a gs1:CertificationDetails;
  gs1:certificationAgency "Foundation FSSC 22000";
  gs1:certificationAgencyURL <https://www.fssc22000.com>.

But I want to write:

# if I have rich data:
<certificate/(ROWNO)> a gs1:CertificationDetails;
  gs1:certificationAgency <https://www.fssc22000.com>.

<https://www.fssc22000.com> a gs1:Organization;
  gs1:organizationName "Foundation FSSC 22000";
  schema:uri <https://www.fssc22000.com>;
  # ... many other props

# if I have just the name:
<certificate/(ROWNO)> a gs1:CertificationDetails;
  gs1:certificationAgencyName "Foundation FSSC 22000"

[VladimirAlexiev]

We're thinking of a writing a blog "Linked Data for Integrated Logistics and Supply Chains", and I thought of something else: the certified* props need to cover the full variety of EPC (TDS) identifiers and the full hierarchy of classes that can have an EPC id.

So far the proposal covers:

• gs1:Product: certifiedProduct
• gs1:IndividualProduct: certifiedProduct
• gs1:Place: certifiedPlace
• gs1:Organization: certifiedOrganization

But the proposal is missing:

• gs1:IndividualObject
  • gs1:IndividualTradeItemPiece
  • gs1:Component
  • gs1:Document
  • gs1:IndividualAsset
    • gs1:MarineVessel ?
  • gs1:ReturnableAsset
    • gs1:ShippingContainer ?
  • gs1:LogisticUnit
  • gs1:Consignment
  • gs1:Shipment
  • gs1:SensorDevice
• gs1:ProductBatch
• gs1:ProductModel
• (Organization)
  • gs1:ServiceRecipient
  • gs1:ServiceProvider

It'd be easy to rename certifiedProduct to certifiedObject and allow it to point to any of these.
However, this won't enable the following cases:

• Gas bottles, road and rail tanks are inspected and certified yearly, to transport particular products (GTIN) so we again need a combination such as certifiedContainer & certifiedProduct to express this
  • (They are also certified for particular conditions like pressure and temperature, but let's leave that aside)
• Perhaps a particular marine vessel (eg tanker) may be certified in combination with some pressurized containers, and

@mgh128 @CraigRe @RalphTro @jmcanterafonseca-iota @shalikasingh @dakbhavesh and others with experience in supply chains:

• Which of the above classes can be "certified"?
• In what combinations?

I should explain what we mean by combination (see "disjunction" vs "conjunction" above):

• certifiedOrganization o1,o2; certifiedProduct pr1,pr2; certifiedPlace pl1,pl2 means that o1&o2 are certified to handle pr1&pr2 at places pl1&pl2 in any combination. But they are not certified for other products or other places
• certifiedPlace plant1,plant2; certifiedProduct pr1,pr2 means that plant1&plant2 are certified to handle pr1&pr2 (without reference to any organization)
• Following this logic, if we generalize certifiedProduct to certifiedObject then
  • certifiedObject ship1,tank1,product1 does NOT mean ship1 and tank1 together are certified to carry product1 but means that these 3 objects are certified INDEPENDENTLY of each other
• I hope we don't need to represent conjunctions of the same kind of object, eg "ship1&ship2 are certified to work only together in formation" or "product1&product2 are certified to be used together" or "tank1,railCar1 are certified to be used together"
  • If we do then we need to represent the logical combinations in an explicit way, which will be a bit more complex

[ghost]

@VladimirAlexiev Your proposal for other classes of objects to have certfications aligns with my knowledge of the Transport & Logistics world. This certainly points out that not all of the GS1 Identification Keys are currently covered in the GS1 Web Vocabulary.

The topic of enhancing certifications was one of the core objectives for this work group. To meet that objective, the work group held a couple free-thinking dicussions earlier in the process to elicit what changes were needed to make certifications fit for purpose. My takeaway from those conversations is that the priority for many users was around Products, Places, and Organizations. I don't recall any strong calls for the ability to reflect certifications of those other classes of objects. There was a stronger emphasis on additional properties and the ability to certify combinations of products, locations, and organizations.

Some of the things you have noted should be fairly straightforward additions. I'm thinking of rail cars & shipping containers that would be identified with a GIAI, gas cylinders that would be identified with a GRAI, and sensors identified with GIAI. But others require some additional thinking... would a model of products be certified or would it be the individual classes of products? Certifications applying to Batches and instances of products is already possible since certifications are declared in the ILMD of an event. I can imagine circumstances where a Service Relationship Provider might declare relevant certifications but the modeling is not straightforward to me.

I say all of this to suggest that discussion is needed to get this right. It's a worthy discussion but I'm concerned that solving for these additional use cases on certification could further delay EPCIS 2.0 delivery. I suggest it would be better for a separate proposal to be submitted to the GSMP process on these additional use cases as a follow-up to our main proposal on certification. That way the use cases will still be captured but it would be a dependency for EPCIS 2.0.

On the latter part of your message about Conjunctions and Disjunctions, this might be a good call discussion. @mgh128 did present a way that the proposal would allow compound certifications to be expressed. I don't recall the details well enough to consider what you have noted above.

[VladimirAlexiev]

@visibleOrigins thanks for the feedback!

Because Certifications should be defined by WebVoc based on the GSMP process, and EPCIS events merely refer to the certification but are not dependent on its details, I think these details should not delay EPCIS.

It is the intent to make WebVoc classes for all of the GS1 Identification Keys (is this the same as TDS?) as per the linked Google sheet. But I don't know whether that will require another GSMP process?

Mark and I thought up "conjunction of disjunctions" together, following the logic of what you see in a faceted UI.
Before that, there was a single field "subjectOfCertificate". But we only thought to split it in 3: organization, place, product.

Now I'm asking: should we split it further?

[VladimirAlexiev]

Discussed on 14 Sep, see https://milecastle.media/dev2021/voc_epcis_extras/CertificationDetails for current version:

• certificationSubject is not split in several props and instead does the AND/OR logic based on the classes of the target objects:

References the object (e.g. product, asset, container), party or location being certified. If multiple values are specified, the certification details apply to the logical conjunction (AND) of groups of different types, while a logical disjunction (OR) applies within each group of the same type. For example, two sibling organizations O1 and O2 can process products P1 and P2 at locations L1 and L2: meaning that either organization can process either product at either location (OR); but the certificate holds for the combinations of organization (either O1 OR O2) AND product (either P1 OR P2) AND location (either L1 OR L2)

• the old prop names certificationAgency (string) and certificationAgencyURL (Organization) are kept for backward compatibility
• all xsd:anyURI literals are converted to object props except certificationURI which is an external site not a semantic URL (the URL of CertificationDetails is the semantic URL of this certificate)

@CraigRe and @mgh128 how about #245 (comment) "Need new fields": 3 more fields that I need for FSSC 22000?

• gs1:initialCertificationDate: was rejected with "could be added later"
• gs1:certificationStatus: ?
• gs1:certificationStatement: ?

[mgh128]

Not yet addressed in public review drafts nor in Work Request to extend gs1:CertificationDetails but noted in a public review comment, recommending further group discussion and potential further work request and update to CBV §9.1.3.1
.

[VladimirAlexiev]

Also, change descr of CertificationDetails

• from "Information about the type of certification issued by a certifying body." (type is wrong because it's an instance)
• to "Certification issued by a certifying body to a certification subject (Organization, Place, Product)."

[ghost]

For gst1:certificationStatus, here is a proposed code list with additional values for us all to consider:

[ghost]

Per discussion on December 14th call, SUSPENSION (Suspension) changed to SUSPENDED (Suspended).

[ghost]

Per Jan 4th MSWG call, group decided to revise the WR to include the gs1:CertificationStatus property expecting a code list with only two values being proposed at this time: Active and Inactive. Other code values considered by the MSWG are being deferred to a later date after industry usage.

Also considered by the workgroup was to separate status and the reasons for Inactive status/Status into two different properties. Decision that it may overcomplicate at this time but by having a streamlined list of code values (Active & Inactive) at this stage, it would leave this possibility open for the future.

[mgh128]

epcis:certificationInfo is missing from the v2.0 XSD - I think it probably belongs immediately after errorDeclaration.
epcis:certificationInfo is missing from the v2.0 JSON Schema - I'll add that
epcis:certificationInfo was present as epcis:certification in the ontology files and UML class diagrams and needs to be renamed epcis:certificationInfo - I'll fix that.

[jmcanterafonseca-iota]

do we have an example of the usage of epcis:certificationInfo ?

…

On Mon, Mar 14, 2022 at 3:25 PM Mark Harrison ***@***.***> wrote: epcis:certificationInfo is missing from the v2.0 XSD - I think it probably belongs immediately after errorDeclaration. epcis:certificationInfo is missing from the v2.0 JSON Schema - I'll add that epcis:certificationInfo was present as epcis:certification in the ontology files and UML class diagrams and needs to be renamed epcis:certificationInfo - I'll fix that. — Reply to this email directly, view it on GitHub <#245 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQEZJLUTFWMBILCD3AVUBHDU75D6BANCNFSM423IP7SA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *IOTA Foundation* Pappelallee 78/79 10437 Berlin, Germany Board of Directors: Dominik Schiener, Navin Ramachandran ID/Foundation No.: 3416/1234/2 (Foundation Register of Berlin)

[VladimirAlexiev]

hi @mgh128 @CraigRe @RalphTro @jmcanterafonseca-iota @ghost

Maybe we should resolve this issue?

• https://www.gs1.org/voc/CertificationDetails and https://www.gs1.org/voc/CertificationStatus exist.
  They don't cover everything proposed above, but I think they are in their final EPCIS 2.0 shape.
• Mark, do the omissions you noted CertificationDetails #245 (comment) still exist?

[mgh128]

Hi @VladimirAlexiev , @CraigRe , @RalphTro , @jmcanterafonseca-iota

Looking at https://ref.gs1.org/standards/epcis/epcglobal-epcis-2_0.xsd , epcis:certificationInfo is present in the v2.0 XSD, immediately after errorDeclaration.

Looking at https://ref.gs1.org/standards/epcis/epcis-json-schema.json , epcis:certificationInfo is present in the v2.0 JSON Schema

Looking at https://ref.gs1.org/standards/epcis/epcis-ontology.jsonld , epcis:certificationInfo is present in the v2.0 EPCIS ontology

Having said that, I have had some recent discussions with @CraigRe and @RalphTro, regarding the merits of embedding certification information within events vs referencing external resources, especially as these relate to the generation of the eventID using the hashing algorithm developed by @RalphTro and his colleagues, detailed in §8.9.2 of https://ref.gs1.org/standards/cbv/2.0.0/ If I remember correctly, we also considered whether it really made sense to almost duplicate https://gs1.org/voc/certification as https://ref.gs1.org/epcis/certificationInfo especially when (confusingly), the GS1 Web vocabulary has a separate property (as a GS1 Digital Link Link Type property) named https://gs1.org/voc/certificationInfo , which is distinct from https://gs1.org/voc/certification and points to an online resource that expresses certification details, even if that is a PDF or bitmap image with no accompanying structured data that is readily machine-interpretable.

@CraigRe or I can probably point you to minutes of recent EPCIS MSWG meetings in which that topic was discussed with the group. We did notice some inconsistencies and if I remember correctly, there may have been errors in the examples regarding the use of epcis:certification vs epcis:certificationInfo. @CraigRe is keeping a 'glitch list' of corrections to be made in v2.1 or v2.0.1

[VladimirAlexiev]

We need two props:

• certification is a cert of gs1:Product, gs1:Organization, or gs1:Place
• certificationInfo is a cert that's relevant to the event, but is not of the event.

I agree that cert info doesn't belong IN the event, but should be stored externally.

As for the https://gs1.org/voc/certificationInfo Digital Link Type: it's a best practice to put various renditions of the same cert (PDF, RDF, whatever) on the same URL and use content negotiation.

[mgh128]

Hi @VladimirAlexiev
I agree - and it looks as though this is the current situation in the GS1 Web vocabulary - or do you disagree?
We just need to make the corresponding clarification in EPCIS 2.0 / 2.1