OntoPedigree: A content ontology design pattern for traceability knowledge representation in supply chains

Tracking #: 687-1897

Monika Solanki
Christopher Brewster

Responsible editor: 
Krzysztof Janowicz

Submission type: 
The sharing of product and process information plays a central role in coordinating supply chains operations and is a key driver for their success. ``Linked pedigrees'' - linked datasets, that encapsulate event based traceability information of artifacts as they move along the supply chain, provide a scalable mechanism to record and facilitate the sharing of track and trace knowledge among supply chain partners. In this paper we present ``OntoPedigree'' a content ontology design pattern for the representation of linked pedigrees, that can be specialised and extended to define domain specific traceability ontologies. Events captured within the pedigrees are specified using EPCIS - a GS1 standard for the specification of traceability information within and across enterprises, while certification information is described using PROV - a vocabulary for modelling provenance of resources. We exemplify the utility of OntoPedigree in linked pedigrees generated for supply chains within the perishable goods and pharmaceuticals sectors.
Full PDF Version: 

Minor revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Victor de Boer submitted on 17/Sep/2014
Minor Revision
Review Comment:

This paper describes an Ontology Design Pattern for modelling supply chain information using so-called pedigrees. The proposed pattern is an abstraction from existing practices in the pharmaceutical domain and it builds on industry standard supply chain information formats. The paper presents the pattern in clear detail and provides two example cases.

I find the paper very pleasant to read and it is well-structured. The motivation for the pattern is very clear and the requirements and competency questions further highlight the modelling decisions. The model builds on well-accepted standards and ontologies, including PROV and GoodRelations, which seem very relevant in this domain.

The examples presented in the paper indicate how the pattern is used in practice and what the added value of this proposed Linked Data solution is for the stakeholders. A link to a reference JAVA implementation is also provided.

There is no real evaluation or shown usage, but reading the specifics for this special issue call, that is not a big point. I would recommend accepting this paper for this special call after addressing some minor points:

- The reference implementation and the references to it in the paper are a bit confusing.
- For example, The paper mentions "LinkedPedigreeGenerator" which I cannot find in the code.
- Also in the code there is mention of a lot of namespaces, but I cannot see the one mentioned in the paper for PED. The authors should clarify this either in the paper or in the "readme" on github.

- p3: In point 2 and 3 of section 2.1, the authors use the term 'interlinked', what is meant exactly by this?

- p3: "As highlighted in Section 1, a linked pedigree is a dataset, identified using an http URI"-> How is this realised? Are Named Graphs used or not?

- p5: What are these restrictions based on. For example, how did the authors decide that a pedigree can have only one serial number. Do these come from domain knowledge the authors have, some external expert, another document?

Grammar and typos
- p2: footnote 5 presents the namespace with a backslash instead of a forward slash in it. Is this correct?
- p4: "PedigreeCreator: An entity linking the pedigree to its creating organisation."-> I would say an entity representing ... (as is done in the next item)
- p4: ". and link it with the pedigrees." -> typo, first full stop needs to be removed
- p4: Footnote 12 is an un-formatted URL
- p7: Here, the authors use IRI instead of URI. I suggest choosing either URI or IRI for the entire paper, unless here there is a specific reason to use IRIs, which is currently not explained.

Review #2
Anonymous submitted on 19/Oct/2014
Review Comment:

This paper presents OntoPedigree, an ontology pattern for representing supply chain information in linked datasets. The need for such a pattern is well motivated. Linked pedigree are a typical case were linked-data would greatly benefit an industry information sharing. As different industries have specific needs and do not necessarily want to embrace a third party ontology, it makes sense to provide a pattern that industries can extend and from which they can derive their own ontology.
The paper is well written, with appropriate examples and illustrations. The pattern is well defined and formalized. The two use cases show that the pattern is effectively able to represent supply chain data. They show the advantage of including de-referenceable URIs in the pedigrees.
While the supply chain information is provided for the industry, it would as well benefit the final customer. However it is not clear if it would be possible to access this information from the final product. In other words, if from the linked dataset accessible from the bundle of tomatoes the downstream data could be accessed. It seems this information does not appear explicitly in the pattern.

A minor issue, the Standard Enforcer Pattern has a description on the ontology design pattern wiki that would be better suited as a link from the paper than an OWL file.

Review #3
By Kary Främling submitted on 30/Oct/2014
Major Revision
Review Comment:

The paper is well written and easy to read. The topic is also important, especially for the industry.

However, the scientific contribution seems to be very small and/or limited. Or in any case, it is not describe or emphasized properly.

Only four references in a journal article, of which two are "self-references" is not really sufficient. Indeed, there should be a much more extensive "background" section with a more thorough literature review. Without such a review, it is not possible to adequately assess the scientific contribution of the paper (see previous point).

Only one typo/linguistic error noticed: "atleast" in two places, should of course be "at least".