Figure 4 - uploaded by Mohammad Rezwanul Huq
Content may be subject to copyright.
Extended entity relationship diagram for our proposed data model. Events are temporal and hierarchical and interpreted by other vocabularies
Source publication
The RFID system with the capability for unique item-level tracking promises a tremendous change in the automa-tion process of identifying, managing and tracking com-modities along supply chains. One of the heaviest burdens in the RFID system is laid on its repository that has to han-dle an enormous amount of timestamped RFID data that are generated...
Contexts in source publication
Context 1
... the business context (Business Step and Disposition) Though the EPCIS speci fi cation recommends four kinds of events that provide necessary information about the com- modity fl ow in most business processes. However, each enterprise may come up with its own events or extensions from these ones to meet their speci fi c requirements. This generalization hierarchy allows us to specialize more events easily as needed and perform temporal operation on the root while searching for speci fi c attribute in the specialization events. Therefore, it answers successfully those queries asking for the event history (e.g., the SimpleEventDataQuery recommended by the EPCIS speci fi cation). The hierarchy of event types and the relationship between them and other vocabularies are described in detail in Figure 4. To avoid line over- lap, in this fi gure, we considered that event types with the same name are the same entity type. Relational database has proved itself over years a good ability of storing large amount of data and protecting in- tegrity through normalization and constraints. Furthermore, all sorts of optimizations have been built into engines so that they are very fast. However, relational database has a lack of semantic features and an inability to represent complex structures and operations. Therefore, it is not nearly strong enough to model all kinds of relationships, both static and dynamic. Meanwhile, the object-oriented database is good at semantic data modeling but complex for query processing and unable to support large-scale systems. These rea- sons have stimulated the emergence of object-relational approach to bene fi t aspects from both models. Data are stored in tables, and we can de fi ne our own data structures and relevant operations for tabular entries, and bene fi t different kinds of object-oriented relationships between objects such as aggregation, association and inheritance. Unfortunately, current database systems, such as Oracle, depend heavily on relational tables when building object- relational features. If we directly use these object-relational features, the performance of our system is much less ef fi cient than purely relational approach. Therefore, before ap- plying object-relational approach, we employ a relational layer (Figure 5) in which we map the EER diagram in previous section into relational tables. Normalization and all constraints are deployed at this layer as in a traditional database. Then, we create object views that materialize events and vocabularies in object-relational approach so that they carry as much semantics as we expect. Query Interface can query repository from views in object-relational layer. Besides, we place instead-of triggers on these views so that incoming data from capture interface can be inserted into repository via object-relational layer. And in fact, application also can access the data via relational layer directly. We store each vocabulary in a table, in which each common attribute of all vocabulary elements corresponds with a table fi eld, and the distinct set of attributes, which is speci fi c for individual element, in another table ( vocabulary- name EXT) whose fi eld named attr value can accept any type of value. Similarly, the parent/children relationships among elements are maintained in the third table ( vocabu- laryname HREF) which consists of two fi elds as the com- posite primary key: parent and child . Example in Figure 6, vocabulary BizLocation in Figure 2 are dispersed in three tables BizLocation , BizLocation Ext and BizLocation Href . In EER diagram (Figure 4), we can see that there are a number of vocabularies to describe each event type. Therefore, besides a table designed for the event itself, we have additional tables for one-many or many-many relationships between that event and other vocabularies. As an example, Figure 7 demonstrates how to maintain information about ObjectEvent in tables. ObjectEvent bizTrans is the table for the the business transaction list one object event can involve in. Above the well-constrained and normalized relational layer, we deploy an object-relational layer, which consists of object views, to materialize rich semantic vocabularies and events. Because each vocabulary and event can be dis- persed in some tables in relational layers, fi rst, for each vo- cabularies and events, we create an corresponding object type encapsulating all the necessary information from sev- eral tables that relate to that vocabulary or event. For exam- ple, the object type for vocabulary BizLocaiton is created as follows Especially, when we create object types for events, we also de fi ne the inheritance relationships among them. We begin with EPCISEvent Type representing the root EPCIS event that just carries the temporal information Other event types inherit EPCIS event type and continue this inheritance hierarchy as deep as we expect. For exam- ple: with EPCList type - a collection or nested tables of string and bizTransaction Ref table - a nested table of an object type consisting of two attributes: bizTransaction and biz- TransactionType . Next step, we create object views based on these objects types and materialize information from separate tables. Again, we apply inheritance relationship among the ob- ject views materializing events. The root object view EPCI- SEvent is created based on EPCISEvent Type and populated by the data coming from table EPCISEvent Table (which is nominal and supposed to contain no data records). Other event views base themselves on their corresponding object types and tables and inherit this the root view. We continue this way until we have the generation hierarchy we want. The EPCIS speci fi cation requires to handle two prede- fi ned queries that support simple ways for accessing application to retrieve EPCIS event instances and vocabulary elements: SimpleEventQuery and SimpleMasterDataQuery. When clients want to use one of the prede fi ned queries, they specify its name and an appropriate list of parameters in form of pairs (attribute name, attribute value) . EPCIS based itself on the query name and then processes the parameter list to return the expected data. For queries on EPC events, EPCIS has to have the ability to retrieve instances in an inheritance chain. The returned events carry as much semantics as they were supposed to have when they were pushed to EPCIS. In this section, we prove how our model successfully answered these requirements by using a simple illustrated query: ” fi nd all events that occurred at location L1 or L2 from time T1 to T2”. This kind of query retrieves all the event instances that sat- isfy the predicates implied in the parameter list which can be summarized as ...
Context 2
... the business context (Business Step and Disposition) Though the EPCIS speci fi cation recommends four kinds of events that provide necessary information about the com- modity fl ow in most business processes. However, each enterprise may come up with its own events or extensions from these ones to meet their speci fi c requirements. This generalization hierarchy allows us to specialize more events easily as needed and perform temporal operation on the root while searching for speci fi c attribute in the specialization events. Therefore, it answers successfully those queries asking for the event history (e.g., the SimpleEventDataQuery recommended by the EPCIS speci fi cation). The hierarchy of event types and the relationship between them and other vocabularies are described in detail in Figure 4. To avoid line over- lap, in this fi gure, we considered that event types with the same name are the same entity type. Relational database has proved itself over years a good ability of storing large amount of data and protecting in- tegrity through normalization and constraints. Furthermore, all sorts of optimizations have been built into engines so that they are very fast. However, relational database has a lack of semantic features and an inability to represent complex structures and operations. Therefore, it is not nearly strong enough to model all kinds of relationships, both static and dynamic. Meanwhile, the object-oriented database is good at semantic data modeling but complex for query processing and unable to support large-scale systems. These rea- sons have stimulated the emergence of object-relational approach to bene fi t aspects from both models. Data are stored in tables, and we can de fi ne our own data structures and relevant operations for tabular entries, and bene fi t different kinds of object-oriented relationships between objects such as aggregation, association and inheritance. Unfortunately, current database systems, such as Oracle, depend heavily on relational tables when building object- relational features. If we directly use these object-relational features, the performance of our system is much less ef fi cient than purely relational approach. Therefore, before ap- plying object-relational approach, we employ a relational layer (Figure 5) in which we map the EER diagram in previous section into relational tables. Normalization and all constraints are deployed at this layer as in a traditional database. Then, we create object views that materialize events and vocabularies in object-relational approach so that they carry as much semantics as we expect. Query Interface can query repository from views in object-relational layer. Besides, we place instead-of triggers on these views so that incoming data from capture interface can be inserted into repository via object-relational layer. And in fact, application also can access the data via relational layer directly. We store each vocabulary in a table, in which each common attribute of all vocabulary elements corresponds with a table fi eld, and the distinct set of attributes, which is speci fi c for individual element, in another table ( vocabulary- name EXT) whose fi eld named attr value can accept any type of value. Similarly, the parent/children relationships among elements are maintained in the third table ( vocabu- laryname HREF) which consists of two fi elds as the com- posite primary key: parent and child . Example in Figure 6, vocabulary BizLocation in Figure 2 are dispersed in three tables BizLocation , BizLocation Ext and BizLocation Href . In EER diagram (Figure 4), we can see that there are a number of vocabularies to describe each event type. Therefore, besides a table designed for the event itself, we have additional tables for one-many or many-many relationships between that event and other vocabularies. As an example, Figure 7 demonstrates how to maintain information about ObjectEvent in tables. ObjectEvent bizTrans is the table for the the business transaction list one object event can involve in. Above the well-constrained and normalized relational layer, we deploy an object-relational layer, which consists of object views, to materialize rich semantic vocabularies and events. Because each vocabulary and event can be dis- persed in some tables in relational layers, fi rst, for each vo- cabularies and events, we create an corresponding object type encapsulating all the necessary information from sev- eral tables that relate to that vocabulary or event. For exam- ple, the object type for vocabulary BizLocaiton is created as follows Especially, when we create object types for events, we also de fi ne the inheritance relationships among them. We begin with EPCISEvent Type representing the root EPCIS event that just carries the temporal information Other event types inherit EPCIS event type and continue this inheritance hierarchy as deep as we expect. For exam- ple: with EPCList type - a collection or nested tables of string and bizTransaction Ref table - a nested table of an object type consisting of two attributes: bizTransaction and biz- TransactionType . Next step, we create object views based on these objects types and materialize information from separate tables. Again, we apply inheritance relationship among the ob- ject views materializing events. The root object view EPCI- SEvent is created based on EPCISEvent Type and populated by the data coming from table EPCISEvent Table (which is nominal and supposed to contain no data records). Other event views base themselves on their corresponding object types and tables and inherit this the root view. We continue this way until we have the generation hierarchy we want. The EPCIS speci fi cation requires to handle two prede- fi ned queries that support simple ways for accessing application to retrieve EPCIS event instances and vocabulary elements: SimpleEventQuery and SimpleMasterDataQuery. When clients want to use one of the prede fi ned queries, they specify its name and an appropriate list of parameters in form of pairs (attribute name, attribute value) . EPCIS based itself on the query name and then processes the parameter list to return the expected data. For queries on EPC events, EPCIS has to have the ability to retrieve instances in an inheritance chain. The returned events carry as much semantics as they were supposed to have when they were pushed to EPCIS. In this section, we prove how our model successfully answered these requirements by using a simple illustrated query: ” fi nd all events that occurred at location L1 or L2 from time T1 to T2”. This kind of query retrieves all the event instances that sat- isfy the predicates implied in the parameter list which can be summarized as ...
Similar publications
Simulation professionals understand the importance of accurate data for model validation. Traditional sources of simulation data come from information technology systems, manual records from staff, observations, and estimates by subject matter experts. This paper discusses how radio frequency identification (RFID) technologies were used on a recent...
Addresses consumer perspectives of Radio Frequency Identification (RFID). States that some consumers put up barriers against new technology, while others welcome innovations. Idengtifies that market leaders can pretty much use this technology as they wish, meaning boom time for consumer product firms and pain for privacy advocates.
Citations
... During the incubation phase, EAGLET's design was primarily theory driven. The following are the main sources for the definition of EAGLET's primitives and structuring rules during this phase: economic theory [55,57,62]; supply chain theory [10,63]; basic descriptions of supply chain operations, such as the core activities taking place in a warehouse [10]; the work on HVSCs in the context of emerging technologies, such as RFID [40,64]; and the primitives and structuring principles underlying the REA-EO [29,30]. ...
... The following are the main sources for the definition of EAGLET's primitives and structuring rules during this phase: economic theory [55,57,62]; supply chain theory [10,63]; basic descriptions of supply chain operations, such as the core activities taking place in a warehouse [10]; the work on HVSCs in the context of emerging technologies, such as RFID [40,64]; and the primitives and structuring principles underlying the REA-EO [29,30]. ...
Recently, technological developments, such as radio frequency identification (RFID), have facilitated the identification of individual things and information sharing regarding their behavior throughout the supply chain. Such developments have generated the capabilities of a highly visible supply chain (HVSC): a supply chain where the location of arbitrary individual things can be determined at any point in time by all appropriate supply chain partners, made possible by an “Internet of Things” for the supply chain, referred to as a “Supply Chain of Things.” A critical component of a Supply Chain of Things is an ontology to facilitate the visibility and interoperability of things along the supply chain. As a result, the objective of this paper is to define an ontology that leverages the availability of an individual thing's (object) identification information within the context of a standard set of economic phenomena that support multiple views in a range of data architectures.
Our design science approach begins with a set of ontological primitives and gradually defines structuring principles that provide guidance for the design of supply chain systems that are characterized by increased visibility and interoperability and which facilitate management of and collaborative decision making about supply chain activities. The EAGLET ontology is named after its five primitives: Event, AGent, Location, Equipment, and Thing. The following are some of its unique characteristics: location and equipment are recognized as ontological primitives, and creating and destroying of containment structures is explicitly modeled; the economic phenomena underlying the supply chain are defined from an independent view, as opposed to a trading-partner view; the supply chain is defined from three different perspectives: the physical flow, the chain of custody, and the chain of ownership; event sequences that resemble the economic scripts underlying the supply chain are defined.
... Tuyen Nguyen et al. proposed an event-based data model for EPC Information Service (EPCIS) repository [5]. They also exploit both object-relational and relational strength to make data rich in semantics and build a generalization hierarchy of events to answer queries about historical events recommended by EPCGlobal's EPCIS specification. ...
The applications of Radio Frequency Identification (RFID) and Electronic Product Code (EPC) in supply chain management have vast potential in improving effectiveness and efficiencies in solving supply chain problems. RFID data, however, have their own unique characteristics – including aggregation, location, temporal and history-oriented – which have to be fully considered and integrated into the RFID data model which is constructed for RFID application system. In this paper, we use an expressive temporal data model for RFID data. This data model is based on Entity-Relation (ER) model with minimum extension and highlights the state history and temporal semantics of the RFID system business processes. We also show common RFID data tracking and monitoring types, and propose methods to express such queries based on this data model.
... (ii) State-based dynamic relationship where tstart and tend attributes are added to represent the lifespan of a state. Below is the glimpse of table structures [5]. In paper [8], the authors have proposed temporal data models. ...
... In paper [5], authors have proposed an extended entity relationship diagram. As mentioned, data in EPCIS fall into two categories: master data (static data) and event data (dynamic data).Master data include (1) class-level Data describing properties for all objects of the same object class (product name, manufacturer, SKU, etc), (2) instance-level Data describing properties of each individual object (date of manufacture, lot number, etc), and (3) business context data providing necessary business context (business locations, transaction type, etc).Event data refer to things that happen at a specific time. ...
The Radio Frequency Identification System (RFID) uses radio waves to transfer data between readers and movable tagged objects. There are variety of applications where RFID data is time-dependent, dynamically changing, in large volumes, and carry implicit semantics. RFID application needs to effectively support such large scale temporal data created by RFID applications. These applications need an explicit temporal data model for RFID data to support tracking and monitoring queries. In addition, they need to have an automatic method to transform the primitive observations from RFID readers into derived data used in RFID-enabled applications. This paper propose an extended temporal and event based data model for such applications.
... (ii) State-based dynamic relationship where tstart and tend attributes are added to represent the lifespan of a state. Below is the glimpse of table structures [5]. In paper [8], the authors have proposed temporal data models. ...
... In paper [5], authors have proposed an extended entity relationship diagram. As mentioned, data in EPCIS fall into two categories: master data (static data) and event data (dynamic data).Master data include (1) class-level Data describing properties for all objects of the same object class (product name, manufacturer, SKU, etc), (2) instance-level Data describing properties of each individual object (date of manufacture, lot number, etc), and (3) business context data providing necessary business context (business locations, transaction type, etc).Event data refer to things that happen at a specific time. ...
The Radio Frequency Identification System (RFID) uses radio waves to transfer data between readers and movable tagged objects. There are variety of applications where RFID data is time-dependent, dynamically changing, in large volumes, and carry implicit semantics. RFID application needs to effectively support such large scale temporal data created by RFID applications. These applications need an explicit temporal data model for RFID data to support tracking and monitoring queries. In addition, they need to have an automatic method to transform the primitive observations from RFID readers into derived data used in RFID-enabled applications. This paper propose an extended temporal and event based data model for such applications.
... Although the type of context data that should be associated with RFID reader events is well known since EPCglobal's definition of the EPCIS, there are only a few publications that address the management of context data. Nguyen et al. (2007) developed an extended Entity Relationship (ER) diagram for EPCIS data and described the characteristics of event and master data in detail. They reviewed other EPCIS data models, especially the ones used in industry solutions such as the Siemens and Sun RFID middleware. ...
The potential of Radio Frequency Identification (RFID) for increasing supply chain efficiency has been stressed by practitioners and researchers alike. For the cross-company exchange of RFID-related data, the industry consortium EPCglobal has specified the EPC Information Services (EPCIS). According to EPCglobal, all RFID-related data recorded by an organization should be stored as EPCIS events in a dedicated database. The information that can be inferred from the EPCIS events stored in the EPCIS repositories will be sufficient to monitor the flow of goods. However, generating an EPCIS event does not only require the data that is provided by the RFID readers but also the corresponding context data (e.g. physical locations, related business process steps and related transactions). For this missing link, i.e. the association of read events and context data, we propose an architectural component called Event Capturing Application (ECA). In this paper we propose a data model for storing and exchanging EPCIS context data in an efficient and standardizable way. We also present an algorithm that can be used to assemble EPCIS events from read events and context data. The functionality of our prototypical ECA was evaluated using noFilis’ RFID middleware CrossTalk and the Fosstrack EPCIS implementation.
... Liu & Wang developed a model in [1] and it was developed further in [2][3][4]. Nguen et al. presented their model which includes business transactions in [5]. Harrison presented categories of RFID data and some query examples in [6]. ...
Equivalent of epsiv5 billion of wood raw material is going to waste in Europe. The reason is that information regarding the raw material is not available throughout the system. An automatic traceability system makes it possible to use the raw material information throughout the forestry wood production system. The RFID-technology can achieve automatic traceability by enabling us to connect the physical world objects with their virtual counterparts. This traceability system needs to have a temporal data model to support tracking of the raw material and monitoring of the processes. In this paper, that data model for the traceability system of the forestry wood supply chain is presented.
... Especially, a virtual objectrelational layer is introduced on the top of relational tables so as to make our data model more comprehensive in terms of semantics and more flexible in terms of applicability on existing databases and future extensibility. Our work is extended from [12]. The paper proposed an event-based data model for EPCIS with two efficient layers. ...
... Other data manipulation operations on views, such as update and delete, can be easily handled by using INSTEAD OF triggers. Further detail on building these views can be found in our previous work [12]. Since object views are virtual, they can be easily changed by redefining object types and data-extracting queries for views. ...
Radio Frequency Identification (RFID) technology is an excellent substitute for barcodes in industry. However, the management of a large amount of RFID data, together with complicated relationships between data, in the context of responding to different kinds of queries is not well supported by traditional databases. Therefore, 1) an eventbased model for managing data and 2) an algorithm for responding to event queries are proposed for RFID repositories in this paper. Our approach is based on the specification of the EPC Information Services (EPCIS) to meet the overall data requirements of the RFID community. Specifically, the object-oriented model is built on the top of relational databases so as to make the proposed combined data model highly flexible and semantic comprehensive. Based on this data model, various complicated predicates implied in different parameters of the predefined event query are interpreted into one single request to the database.
With the development of RFID technology, RFID based applications are wildly used in various fields, especially in supply chain automation. EPC (Electronic Product Code) Information Service, which takes a basic and key role in EPC network system, has become a hot research spot. How to establish highly efficient and extensible distributed EPCIS repositories is an important problem to be resolved. This paper proposed a data model of EPCIS which enables different enterprises to customize their own EPCIS data. We also designed and implemented a configuration mechanism to extract duplicated information and reduce data volume.
