                              
|
 |
Entity
In
the real world, nearly every physical object is
owned by somebody. This "somebody" may
be an individual, corporation, organization or country,
and "owned" may mean legal possession,
management, custodianship or temporary responsibility.
Furthermore, it is the transition of ownership between
parties defines commerce.
Because
of the importance of identifying owners, the Physical
Markup Language will include a mechanism to describe
entities; that is individuals, companies, organizations
or anyone else that can "own" objects.
We use the term entity to describe any party that
has any role or connection with a physical object.
The
concept of an entity, therefore, is any person,
company, organization or group, which owns, manages,
oversees, transport, insures, purchases, sells or
holds physical assets. Since the Physical Markup
Language is focused on business, commerce, industry
and consumers, we will provide descriptions of the
entity relevant for those applications and are needed
for trading parties.
The
primary types of data for an entity will be identification
data and communication channels. This information
is a required to gain further information and to
interaction with an entity.
We
will divide information about the entity into two
parts - inherent information, which does not change
(or which changes very infrequently) and associations,
which grow and shrink with time. Inherent data,
for example, includes the name of the entity. Associations
are physical or virtual locations and communication
channels that are associated with an entity.
Individuals,
companies and organizations may have many associations.
For example, a person may have more than one office,
assistant, job, role, responsibility, affiliation
or home. The idea is to capture in the specification
the network of links among individuals, companies
and organizations to afford more accurate, timely
and efficient communication.
The
primary purpose of the entity is to unambiguously
establish ownership and responsibility for a physical
resource and to create a communication channel.
Clearly, information needed to fully represent an
individual, company or organization is not included
here. These may be included in industry specific
extensions to the Physical Markup Language as described
in Chapter 17.
Entity
The
transition in ownership between parties defines
commerce. We must include a mechanism within the
Physical Markup Language to describe parties -
whether people, companies or organizations. We
will use the term entity
to describe any party that has any role or connection
with a physical object. We introduce the entity
element within PML to describe these parties.
<entity> . . . </entity>
Name
What's
in a name? Names - whether for people or companies
- are very important. Many people, companies and
organizations are particular about the manner
in which their name is presented - and rightly
so. Therefore PML includes a special data structure
name
to contain not only the exact legal name of an
entity, but the manner and style in which it is
to be displayed. A single entity may, therefore,
have many names, which can be selected and presented
depending on application and circumstances.
The
name element includes a
type
attribute that distinguishes the different name
representations. The type
attribute indicates the general type of name,
such as "formal," "legal,"
"corporate," "common," "nick,"
etc.
<name type=string>
. . . </name>
The
name
element contains a string - a human readable alphanumeric
character string, that represents the name of
a person, company, organization or group.
<name type=string>
string
</name>
For
human entities, we provide an optional data structure
that divides the name into a first name, last
name and middle components. We recognize many
names cannot be represented in this manner, but
for those that can these optional elements can
facilitate name interpretation and PML parsing.
We also recognize that the designators first
, last
and middle
are simply convention, in that first
refers to a given name, last
to a family or surname, and middle
to any additional names. We allow one or more
middle
element, to accommodate additional given or family
names.
Each
name
component includes an optional show
attribute that indicates how the name should be
presented. Some individuals, for example, use
initials and others use one or more middle names.
In
addition, the order in which the name
components are encountered determine the order
in which they are presented. Within many cultures,
the family name proceeds the given names.
The
show
attribute allows the following options "none",
"initial", "full".
<entity>
<name type= string
>
string
<first show=[none, initial, full]>
string
</first>
<middle present=[none, initial, full]>
string
</middle>
. . .
<middle present=[none, initial, full]>
string
</middle>
<last present=[none, initial, full]>
string
</last>
</name>
. . .
<name type= string
> . . .</name>
. . .
</entity>
Many
individuals have additional have additional degrees,
ranks, titles, prefixes and suffixes that are
appended onto their names. To provide this flexibility
the name
element allows one or more of both prefix
and suffix
elements.
<entity>
<name type= string
>
string
<prefix> string
</prefix>
. . .
<prefix>
string
</prefix>
<first show=[none, initial, full]>
string
</first>
<middle present=[none, initial, full]>
string
</middle>
. . .
<middle present=[none, initial, full]>
string
</middle>
<last present=[none, initial, full]>
string
</last>
<suffix> string
</suffix>
. . .
<suffix> string
</suffix>
</name>
. . .
<name type= string
> . . .</name>
. . .
</entity>
Again,
the order of the elements determines the presentation
of the name components.
Virtual
EPC
The
entity
element also includes an optional epc
attribute. This attribute holds a virtual EPC,
which designates an external network address that
contains additional information about the entity.
This
is an important attribute, since it allows information
such as address, telephone numbers, points of
contact, etc. to change in one location and propagate
globally.
A
corporate move, a new telephone, a name change
or an additional email can be desseminated immediate
and correctly into all appropriate address books.
<entity
epc= xx.xxxxxx.xxxxxx.xxxxxxxx
>
Associations
Entities
may have many associations. These associations
may be with companies, organization, individuals,
addresses, physical locations or communication
channels. These associations can grow and shrink
with time. Some are permanent, such as heritage
and other are temporary, such as physical position.
The
Physical Markup Language may have zero or more
associations . Associations
in PML represent links to particular
roles such as "spouse", "manager",
"engineer", "foreman", "shipper:,
etc., addresses such
as homes, offices, factories, distributions centers,
laboratories, etc., comunication
channels such as telephone, FAX, email, PDA,
Web Site, etc., and other
entities such as spouses, relations, assistants,
managers, departments, companies, afflications
and organizations.
The
entity
element includes zero or more assoc
elements. The assoc
element includes optional label
and type
attributes. The label
attribute is a human readable string naming the
association and distinguishing one association
from another. The type
attribute represent a general "type"
of association, such as "home", "work",
"affliation", "personal",
"relation", etc.
<entity>
<assoc label= string
type= string
>
<role> . . . </role>
<address> . . . </address>
<channel> . . . </channel>
<entity> . . . </entity>
</assoc>
. . .
</entity>
Each
element in the association entity
element includes zero or more
assoc elements. The assoc
element includes optional label
and type
attributes. The label
attribute is a human readable string naming the
association and distinguishing one association
from another. The type
attribute represent a general "type"
of association, such as "home", "work",
"affliation", "personal",
"relation", etc.
Role
"Chef,
cook and bottle washer." A person may have
only one job, but many different roles. This is
characteristic not only of individuals, but groups,
organizations and even companies. To accomodate
this fine distinction, the assoc
element provides an optional role
element, which stores a role related to the association.
For
this version of PML, the role
element is simply a human-readable, text string
designating a particular role.
Address
The
address element includes
a series of subordinate elements defining a physical
location of the association. These include the
following optional elements:
room, suite, number, building, local, street,
city, county, province, state, region, country
and code . Note the
address element may include one or more
local elements corresponding to local subdivisions
used in many countries. The interpretation of
these elements is determined by the designation
of the country. We assume address schemes are
relatively consisten within a country. The address
element also includes zero or more
channels , since a physical location may
have a communication channel separate from the
entity. For example, a loading dock may have a
telephone, which is not linked to any individual,
but to the address. The address specification
is summarized as follows:
<address>
<room> String
</room>
<suite> String
</suite>
<number> String
</number>
<building> String
</building>
<local> String
</local>
.
. .
<local> String
</local>
<street> String
</street>
<city> String
</city>
<county> String
</county>
<province> String
</province>
<state> String
</state>
<region> String
</region>
<country> String
</country>
<code> String
</code>
<channel> ... </channel>
</address>
Channel
Finally,
a communication channel represents a method and
mode of communication with an entity with respect
to a particular association. The
channel element includes a
type attribute - "Voice,"
"Email," "FAX," "Mobile,"
"Pager," "Web," "Radio,"
"Telex," "TTY/TDD" or
"Other" - and
a string representing the actual number or communication
address address.
<channel
type=["Voice", "Email", "FAX",
"Mobile",
"Pager", "Web",
"Radio", "Telex,"
"TTY/TDD"]>
String
</channel>
The
shipping manager of a hypothetical store 'S.Mart
Store's, 'Robert Mooreland,' has a number of
associations including a personal communication
system (a cell phone), an office and the receiving
docks. The office, located in a regional distribution
center, also has an association with the larger
'S.Mart Stores Corporation.' In this way, ownership
and responsibility of physical assets may be
captured and traced within this data structure.
The
illustration shown in the Figure graphically
represents these links, as well as indicates
the communication channels. The sample file
provides a simple PML encoding of this information.
An actual listing of all the links, address
and communication channels would likely be much
larger.
The
idea here is to more accurate capture often
competing and disparate associations the inventory
manager may have, and to provide a clear representation
of responsibility and communication.
<middle>Douglas </middle>
<channel type="Mobile">513-632-8229</channel>
<assoc label= "dock" type= "work">
<role>Shipping Manager</role>
<channel type="Voice">513-633-2938</channel>
<street>Commerce Park Road</street>
<entity epc=01.000018.019919.000192837>
</entity>
<assoc label= "shipping office"
type= "work">
<role>Shipping Manager</role>
<channel type="Voice">513-633-2942</channel>
<channel type="Fax">513-633-2953</channel>
<channel type="Email">rmooreld@smart.com</channel>
<street>Commerce
Park Road</street>
<entity> ..."link S.Mart Stores"...
</entity>
<entity
epc= xx.xxxxxx.xxxxxx.xxxxxxxx
>
<name type= string
>
string
<first show=[none, initial, full]>
string
</first>
<middle present=[none, initial, full]>
string
</middle>
. . .
<middle present=[none, initial, full]>
string
</middle>
<last present=[none, initial, full]>
string
</last>
</name>
<assoc label=string
type=string
>
<role> String
</role>
<address>
<room> String
</room>
<suite> String
</suite>
<number> String
</number>
<building>
String
</building>
<local> String
</local>
. . .
<local> String
</local>
<street> String
</street>
<city> String
</city>
<county> String
</county>
<province> String
</province>
<state> String
</state>
<region> String
</region>
<country> String
</country>
<code> String
</code>
<channel> ... </channel>
</address>
<channel type=["Voice", "Email",
"FAX",
"Mobile", "Pager", "Web",
"Radio", "Telex,"
"TTY/TDD"]>
String
</channel>
<entity> . . . </entity>
</assoc>
</entity>
|
|
|
| |
|
|
|
|
|
|
