Open mgh128 opened 3 years ago
VladimirAlexiev
commented
3 years ago certificationInfo should be merged to certification, see https://github.com/gs1/WebVoc/issues/20. The shorter name is better, and "Info" is a parasitic wordcertificationType (AnyURI), eg <organicFood>.VladimirAlexiev
commented
3 years ago VladimirAlexiev
commented
3 years ago 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 thereofVladimirAlexiev
commented
3 years ago From today's meeting:
<object> -> gs1:certification -> CertificationDetails -> gs1:certificationSubject -> <object> are inverses<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:
<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)?
mgh128
commented
3 years ago 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
commented
3 years ago @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
commented
3 years ago 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 ?
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
gs1:certificationSubject then gs1:certification 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 https://github.com/gs1/EPCIS/issues/245#issuecomment-828503514, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSXRL42BXR2TKRLGQ4MWSLTLALZ7ANCNFSM423IP7SA .
VladimirAlexiev
commented
3 years ago merge gs1:certification and gs1:certificationInfo
https://github.com/gs1/WebVoc/issues/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
commented
3 years ago The above diagram is included in chapter "EPCIS Semantics".
VladimirAlexiev
commented
3 years ago @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:
gs1:certificationAuditDategs1:certificationStartDategs1:certificationEndDateNeed 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)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?certificationSubject to 3 optional multivalued fields eg named and described ascertifiedOrganization, 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"Clarifications:
gs1:certificationStartDate as "Starting date of validity of the certification: original or in the current recertification cycle."gs1:certificationURI: is that of the particular certificate instance (corresponding to certificationIdentification) or of the kind of certificate (corresponding to certificationStandard)mgh128
commented
3 years ago 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
commented
3 years ago 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 https://github.com/gs1/WebVoc/issues/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"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:
But the proposal is missing:
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:
certifiedContainer & certifiedProduct to express this
@mgh128 @CraigRe @RalphTro @jmcanterafonseca-iota @shalikasingh @dakbhavesh and others with experience in supply chains:
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 placescertifiedPlace plant1,plant2; certifiedProduct pr1,pr2 means that plant1&plant2 are certified to handle pr1&pr2 (without reference to any organization)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
ghost
commented
3 years ago @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
commented
3 years ago @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
commented
3 years ago 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)
certificationAgency (string) and certificationAgencyURL (Organization) are kept for backward compatibilityxsd: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 https://github.com/gs1/EPCIS/issues/245#issuecomment-866695217 "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
commented
3 years ago 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
commented
3 years ago Also, change descr of CertificationDetails
ghost
commented
2 years ago For gst1:certificationStatus, here is a proposed code list with additional values for us all to consider:
ghost
commented
2 years ago Per discussion on December 14th call, SUSPENSION (Suspension) changed to SUSPENDED (Suspended).
ghost
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago 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 https://github.com/gs1/EPCIS/issues/245#issuecomment-1066858944, 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
commented
1 year ago hi @mgh128 @CraigRe @RalphTro @jmcanterafonseca-iota @ghost
Maybe we should resolve this issue?
mgh128
commented
1 year ago 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
commented
1 year ago We need two props:
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
commented
1 year ago 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
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.