CA2351696A1 - System for implementing privacy policies written using a markup language - Google Patents
System for implementing privacy policies written using a markup language Download PDFInfo
- Publication number
- CA2351696A1 CA2351696A1 CA002351696A CA2351696A CA2351696A1 CA 2351696 A1 CA2351696 A1 CA 2351696A1 CA 002351696 A CA002351696 A CA 002351696A CA 2351696 A CA2351696 A CA 2351696A CA 2351696 A1 CA2351696 A1 CA 2351696A1
- Authority
- CA
- Canada
- Prior art keywords
- data
- prml
- role
- name
- oid
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/123—Storage facilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/14—Tree-structured documents
- G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Health & Medical Sciences (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Artificial Intelligence (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
~~ystem for Implementing Privacy Policies written using a markup language In today's corporate environment, it is often difficult of coordinate a corporate privacy policies with access control policies. A set of <;ostly processes is necessary to assure that the two policies are consistently coordinated.
SUMMARY OF THE INVENTION
Privacy Rights Markup Language (PRML) is the foundation for the solution to this problem.
PRML is an XML-based language that allows for the definition of objects-roles, operations, data elements, purposes, constraints, actions and transformations- and a mechanism for linking these objects together to form PRML privacy declarations. Declarations specify that a role can do an operation on a data element for a purpose if (optionally) certain constraints are satisfied. It can also optionally specify that an action should take place when this occurs and that the data element should be subject to a transformation before the operation can occur. A privacy policy is a collection of such PRML declarations.
The PRML standard offers a comprehensive set of constructs in order to represent privacy policies in full compliance with the Fair Information Practices (http://www.epic.or~~rivac~iconsumer/code; fair info.html).
PRML enables an organization to formalize its privacy policies and corresponding operational procedures. The language also enables the specification of policies around altering privacy policies.
Example: A PRML document may specify the following declaration: When a PRML
document is modified (and thus a privacy policy changed), all individuals that have consented to the current policy must be notified.
PRML is flexible to unambiguously define every possible privacy policy a corporation might wish to enforce.
PRML can be used in an auditing capacity. In this capacity, instead of interpreting a declaration as specifying that a role can do an operation on a data element for a purpose, it can be interpreted to specify that a role did an operation on a data element for a purpose.
A mechanism for document extension is specified. A single PRML file may not contain a full set of declarations or objects.
Example: One PRML file may contain the objects and declarations associated with the activities of the marketing department while another contains the objects and declarations associated with the activities of the customer care department.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Prior to an in depth specification of PRML objects and declarations, some examples may aid the reader.
~ An example of a role is: physician.
~ An example of an operation is: view.
~ An example of a purpose is: providing medical care.
~ An example of a data elerraent is: a patient's medical record containing the patient's name, address and medical condition.
~ An example of a constraint is: the physician is the patient's doctor.
~ An example of an action is: the patient must be notified via email when her record is accessed.
~ An example of a transforrnation is: the HIV test in the medical record should be replaced with "HIV test result not available".
~ An example of a declaration is: A physician can view a patient's medical records for the purpose of providing medical care if the physician is the patient's doctor. The patient should be notified via email when this occurs. The HIV test result in the medical condition should be replaced with "HIV test result not available" in this circumstance.
'terminology and Conventions ~ PRML Declaration: A statement that establishes a permissible relationship between PRML
objects.
~ PRML Object: .A role, operation, data element, purpose, constraint, action, or transformation.
PRML declarations refer to these objects and only these objects.
~ PRML File: An XML file containing a full or partial set of PRML object definitions and/or declarations.
~ PRML Document (Also referred as PRML policy): A PRMI_ file or collection of PRML files containing a comprehensive set of declarations and objects definitions.
~ UML Notation: The objects and attributes of a PRML policy document are described informally in this specification with Unified Modeling Language (LTML) static object model diagrams. The UML object diagrams capture the information and relationships, which are then represented in an XML format according to Document Type Definition (DTD) files. The UML class diagrams capture the object types (classes), their attributes, the attribute types, and the relationships between classes.
XML Notation: <Text i.n courier> is used to represent portions of an XML file.
F'RML Document Structure A PRML document is composed of four sections: the RI)F Header, the Object Dictionary, the Declaration Set, and the Data Schema.
RDF Header The Resource Definition Framework (RDF) specifies the file header. The header includes document meta-data information such as author, title, subject, and creation date.
C)bject Dictionary This section describes the contents of the object dictionary section of a PRML
file.
The purpose of the object dictionary is to define all objects that make up the declarations. All objects referenced in the set of declarations must be declared in the object dictionary. The dictionary includes exactly seven sets- one for each type of PRML object: <role-set>, <operation-set>, <purpose-set>, <data-set>, <constra:int-set>, <action-set>, and <transformation-set>.
Each set contains zero or more PRML objects of the corresponding type. Each set may refer to an external P RML file through the <external--ref-location> element.
The following diagram shows the data model of the PRML object dictionary:
PRML objects defined in the dictionary have several attributes. Every object has an Object ID (OID).
The OID must be unique within the class for each organization. This means that one corporation must not have two roles, for example, with the same OID. However, a role and a purpose may (but are never required to) share the same OID. PRML does not use the ID and IDREF
keywords as specified in the XML specification because the PRML, document may refer to objects residing in a different PRML file. All PRMI. objects also have human-readable names. All objects may optionally include a human-readable description.
Attributes of PRMI. Objects:
Element Description DatatypeApplicable i Objects oid A unique object ID- Key All must be unique among all objects within a class name Human readable name String All Description Human readable descriptionString All (optional) extends Reference of the oid(s)Key Roles, Purposes, of the base object (optional) and Operations label-ref Reference of the labelKey Data Elements of a <data-def > element in the <data--schema> section. (See section 0) recipient- Reference to the oid Key Operations of the role on idref the receiving end of this operation (typically used in the case of data sharing) (optional) label The label is assumed String Constraints, to refer to a function that implements Actions, and the constraint, action, Transformations or tranformation (optional) A description of attributes specific to certain. objects, and corresponding examples for each object type follow.
Stoles Examples of roles include 'customer care rep', 'customer care supervisor, and 'database administrator.' PRML does not include the concept of 'user'. Instead, all users play a particular role or roles at any given moment. PRML distinguishes users by their roles because privacy policies are created in terms of roles. A policy grants or prohibits (which is implied by not granting) access to a certain role, regardless of which specific user happens to be playing that role.
One role can extend multiple other roles. The fact that an role X extends role Y means that if a declaration exists that contains a reference to X, an implied declaration exists with a reference to Y.
For example, a child operation 'credit check' may extend a base operation 'read.' This means that if the operation 'credit check' is permissible, the base operation 'read' is also implied to be permissible.
'To extend an object, the <ext.ends> element of the child object should reference the base object.
Example:
<role-set>
<role>
<oid>ROLE-001</oid>
<name>CUSTOMER_CARE._REP</name>
<description>Customer care reps are users in the CS
department.</description>
</role>
<role>
<oid>ROLE-002</oi.d>
<name>CUSTOMER_CARE;_SUPERVISOR</name>
<description>Customer care supervisors are extensions of customer care reps.</description>
<extends>
<base-id>ROLE-U01</base-id>
</extends>
</role>
</role-set>
~Dperations Examples of operations include 'read'. 'update', 'delete', 'send email,' and 'send surfing profile to ad network.' Operations can define complex functions that require the combination of several atomic operations. Examples of non-atomic operations include 'send email,' and 'check credit.' The optional <recipient-idref> element is used to reference the recipient role for operations that share data with a particular role. A declaration may allow sharing of data only with a particular recipient.
Similar to roles, operations may form a hierarchy using the <extends> element.
Example:
<operation-set>
<operation>
<oid>OPERATION-ool</oid>
<name>Read</name>
</operation>
<operation>
<oid>OPERATION-002</oid>
<name>Send surfing profile to ad net~,vork</name>
<extends>
<base-id>OPERATION-001</base-id>
</extends>
<recipient-idref>ROLE-001</recipient-idref>
</operation>
</operation-set>
Purposes A Purpose object provides the context for performing same operation on some data. A declaration can indicate that an operation is permission only if the operation is executed for a specific purpose.
Simila to roles and operations, purposes may form a hierarchy using the <extends> element.
Example:
<purpose-set>
<purpose>
<oid>PURPOSE-001</oid>
<name>providing customer care</name>
<description />
</purpose>
</purpose-set>
Data Elements Data elements are objects that group various pieces of data as defined in the data schema. The decoupling of physical data location and declarations isolates the declarations from changes of the data location (e.g. changes to a database schema). When a database schema changes, declarations remain unchanged unless personal information is added or removed. For a description of how phyical data locations are represented, see section 0.
Example:
<data-set>
<data>
<oid>DATA-001</oid>
<name>email</name>
<label-ref>email</label-ref>
</data>
</data-set>
nonstraints All constraints referred to by a declaration must be satisfied for the operation to be considered permissible. A constraint in a PRML document contains a label. This label should refer to a function returning a Boolean value which is implemented by some application.
Example:
<constraint-set>
<constraint>
<oid>CONSTRAINT-007.</oid>
<name>Consent has been granted by the user referred to by the data element</name>
<label>OracleDB.StoredProcs.IsConsent</label>
</constraint>
</constraint-set>
A declaration can contain a reference to CONSTRAINT_001, to indicate that, for example, a role can perform an operation on a data element only if consent has been granted by the user referred to by the data element. The label 'OracleDB.StoredProcs.IsConsent' refers to a function that returns true if the declaration should be permissible and false c>therwise.
l~ransformations When a declaration refers to a data-access operation, an optional transformation object can be specified. Transformations control how the data should be changed prior to delivering it to the requesting user when the data access operation is granted. For example, a declaration can request the data be generalized before a particular role can read the data. As for constraints, the label is assumed to refer to a function that implements the transformation.
Example:
<transformation-set>
<transformation>
<oid>TRANFORMATION-001</oid>
<name>Remove HIV test results</name>
<label>OracleDB.StoredProcs.RemoveHIVResult</label>
</action>
</action-set>
/~Ct1o11S
Actions are procedures that should be executed whenever a declaration takes effect. As for constraints and transformations, the label is assumed to refer to a function that implements the action.
Example:
<action-set>
<action>
<oid>ACTION-001</oid>
<name>NOtify user' <name>
<label>OracleDB.~~toredProcs.SendEmail</label>
</action>
</action-set>
(Declaration Set A privacy policy consists of multiple PRML. declarations. Each declaration creates a permissible relationship between PRML objects as defined in the Object Dictionary. To build a set of all permissible relationships, the following algorithm is used:
~ By default, no relationships are permissible. No roles can do any operations on any data elements for any purpose.
~ If a declaration exists for a relationship, then that relationship is permissible.
A declaration object consists of the following elements:
Element Description Datatype oid A unique object ID- must be unique Key "-- among all declarations name Human readable name String description Human readable descriptionString (optional) role-idref Reference to an oid of Key a role object operation-idref ' Reference to an oid of Key an operation obj ect purpose-idref Reference to an oid of Key a purpose object data-idref Reference to an oid of Key a data object transformation-- ,A transformation and See diagram (optionally) specifier corresponding parameters.below The paramters are passed to the function that implements the transformation.
constraint-specifier-,A set of constraints See diagram and (optionally) set corresponding parameters.below The paramters are passed to the function that implements the constraint.
action-specifier-setA set of actions and (optionally)See diagram corresponding parameters.below The pararnters are passed to the function that implements the action.
Parent-declaration Reference of the oid of Key the parent declaration (used if this is an implicit declaration) (optional) i legislation-ref- The LIRI is the legislationUriReference that mandates location the existence if this declaration - -- (optional) -The three specified sets refer to an constraint. Action, and transformation objects within the dictionary and provide parameters. The parameters are not defined by this specification;
they are used by implementers of transformations, constraints, and actions to allow implementation re-use by multiple declarations.
The static diagram is as follows:
Example Declaration:
<declaration-set>
<declaration;>
<oid>DECLARATION-001</oid>
<name>purge-email</name>
<description>This declaration allows the purging of an email address.
<role-idref>ROLE-002</role-idref>
<operation-idref>OPERATION-001</operation-idref>
<purpose-idref>PiTRPOSE-002</purpose-idref>
<data-idref>DATA-001</data-idref>
<action-specifies-set>
<action-specifies>
<operation-idref>ACTION-004</operation-idref>
<prope.rty-set>
<property>
<name>pusge-email-address</name>
<value type="retention-calendar">30</value >
</prcperty>
</property-set>
</action-specifier>
</action-specifies-set>
</declaration>
</declaration-set>
I=xplicit and Implicit Declarations In the Object Dictionary, roles, operations, and purposes can be structured in a hierarchy using the <extents> relationship (see section 0). When a declaration contains a reference to an object X that has an <extents> relationship (the object X extends an object Y, for example), implicit declarations exist. The implicit declaration is a declaration that is identical to the original declaration with the exception that object Y replaces object X in the implied declaration. The implicit declarations may or may not explicitly appear in a PIUvIL file. However, if they do appear, the <parent-declaration>
element must appear and reference the original declaration. If the original declaration is subsequently deleted from the PRML file, the implied declaration must also be deleted.
For example, a PRML declaration 'customer-care-agent can send email to customer' uses operation 'send email'. This operation may extend operation °read'. In order to send email a user will need permission to read the customer's email address. So the explicit declaration above leads to the implicit declaration 'customer-care-agent can read email address.
Data Schema 'Che goal of data representation in PRML is to provide sufficient abstraction to eliminate the need to re-write declarations when the storage of data changes (e.g. a database data structure is modified), while providing the ability to reference a data element's exact location (e.g. a specific column in a database).
The following diagram demonstrates how data is represented and referenced:
<declaration-set>
<declaration>
<dictionary>
<data-set>
<data-set-id <data> -<role-:Ld> oid>
... label-ref>
:data-schexr~a>
<data-def:>
<label> ~"
<data-strut-ref>~
<data-stru~~t>~
<labels <name>
Declarations must contain a <data-set-id> element. The <data-set-id> element refers (via an <oid>) to a <data> element in the <data-set> of the <dictionary>. A <data>
element contains a <label-ref> element which references (via a <label>) a <data-def> element in the <data-schema>. An optional (or several optional} <data-struct-ref> elements) contained in a <data-def> element reference (via a <label>) a <data-struct> element which is contained in the <data-schema> element. The <data-struct> element contains a <name> element which identifies where the data is. The format of this description is not specified, but could be, for example, the "database.schema.table.column" tuple where the data is physically located.
Example:
<declaration-set>
<declaration>
<data-set-id>DATA-001</data-set-id>
</deolaration>
</declaration-set>
<dictionary>
<data-set import="dat:a-def.xml" »
<data>
<oid>DATA-001</oid>
<name>Customer Contact Info <label-ref>#cu:>tomer-contact-info</label-ref>
</data>
</data-set>
</dictionary>
The contents of the data-def.xml file:
<data-schema>
<data-def>
<label>customer-contact-info</label>
<data-struct-ref>#custEmailAddr</data-struct-ref>
<data-struct-ref>.#custName</data-struct-ref>
</data-def>
<data-struct>
<label>custName.firstName</label>
<name>OracleDB.CUST_INFO.CUST_TABLE.NAME</name>
</data-struct>
<data-struct>
<label>custName.lastName</label>
<name>OracleDB.CUST_INFO.CUST_TABLE.NAME</name>
</data-struct>
<data-struct>
<label>custEmailAddr</label>
<name>OracleDB.CL~ST_INFO.CUST_TABLE.EMAIL</name>
</data-struct>
<data-def>
<label>customer-surfing-profile<jlabel>
<data-struct-ref:.htap://someplace.com/schema#profile</data-struct-ref>
</data-def>
</data-schema>
~ A <data-def > element is not required to contain a <data-struct-ref >
element . If no <data-struct--ref> element exists, the data exists, but its description is unavailable or not required.
~ <data-set> elements can include the import--URI attribute which will indicate that the specified data is described in a <data-schema> element of the referenced document. It is recommended that Data Schemas be defined in a separate file, so this attribute should typically be present, but it is not required. If this attribute is not present, the PRML file must contain a <data-schema> that describes the <data> items.
~ There must be exactly one <data-set-id> per declaration.
~ When referencing a <data-def> or <data-struct> which is contained in the document, you must use the URI convention of placing, a hash ('#') character in front of the name. This character does not appear in the <name> element.
~ The <data-struct> elements describe the structure of various types of data elements. Note that different <data-def > elements can actually have the same structure simply by pointing to the same <data-struct> element(s). Each <data-struct> can optionally point to a local or remote <data-struct> that further defines the description of the data.
~ A <data-struct-ref> element can reference multiple <data-struct> elements.
The <data-struct-ref> string references all <data-struct> elements for which the <data-struct-ref>
string is aprefix of the <data-struct-ref> <label> element. The same logic applies to a <data> <label-ref> element and a <data-def> <label> element.
Conversion between PRML Data Schema and P3P
The following guidelines indicate the relationship and can be used to assist in the conversion from one format to the other. Familiarity with the P3P specification is assumed.
~ PRML data definitions provide a name and an optional description. There is no "short-description"
attribute, which can be specified so these are never generated when converting to a P3P data schema.
~ P3P data elements have an attribute "optional" while PRML does not. This attribute (defaulted to "no") indicates whether or not a visitor to a site can withhold the specified piece of data. When convening from PRML to f3P, this value should be explicitly set to "no." Since PRML deals with releasing data rather than collecting it, a visitor to the site should be obliged to provide it.
~ PRML does not define data categories. P3P can attach categories to DATA, DATA-DEF or DATA-STRUC'h elements in order to provide a hint regarding the intended use of the data. This must be specified somewhere inside a P3P data schema. One means is to use P3P's extension mechanism and assign the following for each DATA-DEF:
<CATEGORY><other-category>PRMh Data Schema</other-category></CATEGORIES>
~ The <data-set> element reaps directly to DATA-GROUP. <data-set> can specify an "import" attribute. This also maps directly to ''base". It is assumed that the PRML data-schema will always be in a separate file. In this case, the link to that file will be identified through a "base" attribute specified for the <DATA-GROUP> element. If the PRML data-schema is exported to the P3P file itself, the "base" attribute value must be set to the. empty string ("").
~ When converting PRML <data> elements to P3P <DATA> elements, the <name>
element must be converted to the attribute "ref'.
~ The <data-def > element maps to P3P's <DATA-DEF>. The <name> element becomes the "name" attribute. Similarly, the <name> element of a <struct-ref > element becomes a "structref' parameter. There is no equivalent to the "short-description"
attribute. Since this is optional in P3P, the conversion process does not specify it.
~ The PRML <data-struct> elements map to P3P~S <DATA-STRUCT> elements and are treated the same way as <data-def> elements.
~ Within PRML data definitions, instances of <description> elements become <horlG-DESCRIPTION> when transferred to P3P data schemas.
Examples- Privacy Policies Expressed in PRML
'The following examples are based on hypothetical, non-trivial privacy policies. Note that each privacy policy and correspondent PRML: document would be portions of a comprehensive set of policies.
:sample PRML Document A
The following policy is encoded in the PRML document below:
~ A customer care rep (role) may create (operation) an e-mail address (data element) in order to create an account (purpose). This email address must be deleted from the system no later than thirty (30) days after its creation (action). A customer care rep (role) may read (operation) a customer's email address (data element) in order to provide customer care (purpose) only if there is a pending transaction (constraint). A software module called an operations agent (role) may delete (purpose) the email address (data element] in order to satisfy the company's minimal retention policy (purpose).
<?xml version="1.0" ?>
<!DOCTYPE prml SYSTEM "prml-vl.U.dtd">
<prml>
<RDF xmlns:dc="http://purl.org/metadata/dublin core#">
<Description />
</RDF>
<dictionary>
<role-set>
<role>
<oid>ROLE-CUSTOMER-CARE-REP</oid>
<name>Customer care rep</name>
<description>Customer care representative. This role is assigned to all users of CRM system</description>
</role>
<role>
<oid>ROLE-OPERATIONS-AGENT</oid>
<name>OPERATIONS AGENT</name>
<description>A software module that assures that all data held in customer database respects minimal retention guidelines . </descript:ion>
</role>
</role-set>
<operation-set>
<operation>
<oid>OPERATION-DELETE</oid>
<name>delete</name>
<description /:.
</operation>
<operation>
<oid>OPERATION-CREATE</oid>
<name>create</name>
<description />
</operation>
<operation>
<oid>OPERATION-SEND-EMAIL</oid>
<name>Send Email<:/name>
<description>emai.l correspondence</description>
</operation>
</operation-set>
<purpose-set>
<purpose>
<oid>PURPOSE-MINIMAL-DATA-RETENTION</oid>
<name>minimal-data-retention</name>
</purpose>
<purpose>
<oid>PURPOSE-PROVIDE-CUST-CARE</oid>
<name>providing customer care</name>
</purpose>
<purpose>
<oid>PURPOSE-CREATE-ACCOUNT</oid>
<name>Create account</name>
</purpose>
</purpose-set>
<data-set>
<data>
<oid>DATA-EMAIL</oid>
<name>email</name>
<label-ref>#email</label-:ref>
</data>
</data-set>
<constraint-set>
<constraint>
<oid>CONSTRAINT-PENDING-TRANSACTION</oid>
<label>pending-transaction-exists</label>
<name>There is an pending transaction.</name>
</constraint>
</constraint~-set>
<transformation-set: />
<action-set>
<action>
<oid>ACTION-PURGE-EMAIL-ADDRESS-TIMER</oid>
<label>purge-emai.l-address-timer</label>
<name>purge-email.-address-timer</name>
</action>
</action-set>
</dictionary>
<data-schema>
<data-def>
<label>email</labe:l.>
<data-struct-ref>userdata.email</data-struct-ref>
</data-def>
<data-struct>
<label>userdata.email</label>
<name>OracleDB.schema.table.email</name>
</data-struct>
</data-schema>
<declaration-set>
<declaration>
<oid>DECL-1</oid>
<name>purge-email.</'name>
<role-idref.>ROLE-CUSTOMER-CARE-REP</role-idref>
<operation-idref>OF~ERATION-CREATE</operation-idref>
<purpose-idref>PURPOSE-CREATE-ACCOUNT</purpose-idref>
<data-idref>DATA-EMAIL</data-idref>
<action-specifies-~,et>
<action-specifier>
<operation-idref>ACTION-PURGE-EMAIL-ADDRESS-TIMER</operation-idref>
<property-set>
<property>
<name>purge-email-address</name>
<value type="retention-calendar">30</value >
</property>
</property-set>
</action-specifier>
</action-specifies-set>
</declaration>
<declaration>
<oid>DECL-2</oid>
<name>email-correspondance</name>
<role-idref>ROLE--CUSTOMER-CARE-REP</role-idref>
<operation-idref>OPERATION-SEND-EMAIL</operation-idref>
<purpose-idref>PiJRPOSE-PROVIDE-CLJST-CARE</purpose-idref>
<data-idref>DATA--EMAIL</data-idref>
<constraint-speci.fier-set>
<constraint-specifier>
<constraint-i,dref>CONSTRAINT-PENDING-TRANSACTION</constraint-idref>
<property-set:>
</property-set>
</constraint-specifier>
</constraint-spec:ifier-set>
</declaration>
<declaration>
<oid>DECL-3</oid>
<name>email-correspondance</name>
<role-idref>ROLE-OPERATIONS-AGENT</role-idref>
<operation-idref>OPERATION-DELETE</operation-idref>
<purpose-idref>PURf>OSE-MINIMAL-DATA-RETENTION</purpose-idref>
<data-idref>DATA-EMAIL</data-idref>
</declaration>
</declaration-set>
</prml>
:3ample PRML Document B
'The following policy is encoded in the PRML document below:
~ Marketing representatives (role) may send email (operation) in order to do targeted advertising (purpose).
Note the following implicit declaration also exists in the PRML document:
Marketing representatives (role) may read (operation) a customer's email addres (data) in order to do targeted advertising (purpose).
<?xml version="1.0" ?>
<!DOCTYPE prml SYSTEM "prml-vlØdtd">
<prml>
<RDF xmlns:dc="http://purl.org/metadata/dublin core#">
<Description />
</RDF>
<dictionary>
<role-set>
<role>
<oid>Role-1</oid>
<name>MARKETING_REPRESENTATIVE</name>
<description>Marketing representative. This role is responsible for communicating promotion campaigns</description>
</role>
</role-set>
<operation-set>
<operation:7 <oid>Operation-1</oid>
<name>Read</name>
</operation>
<operation:>
<oid>Operation-2</oid>
<name>Send Email</name>
<extends>
<base-.id>Operation-1</base-id>
</extends>
</operation>
</operation-set>
<purpose-set>
<purpose>
<oid>Purpose-1</oid>
<name>Targetted advertising</name>
</purpose>
</purpose-set>
<data-set>
<data>
<oid>Data-1</oid>
<name>Customer~s email address</name>
<label-ref>email-address</label-ref>
</data>
</data-set>
<constraint-set/>
<transformation-set />
<action-set />
</dictionary>
<data-schema>
<data-def>
<label>email-address</label>
<data-struct-ref>#userdata.email_address</data-struct-ref>
</data-def>
<data-struct>
<label>userdata.email address</label>
<name>OracleDB.userschema.userdata.email address</name>
</data-struct>
</data-schema>
<declaration-set>
<declaration>
<oid>Declaration-1<:/oid>
<name>Reading email address to provide targeted advertising</name>
<role-idref>ROle-1<:/role-idref>
<operation-idref>Operation-2</operation-idref>
<purpose-idref>Purpose-1</purpose-idref>
<data-idref>Data-1</data-idref>
</declaration>
</declaration-set>
</prml>
iCommonly Used Objects and Declarations A base set of commonly used objects and declarations will be provided to simplify the creation of PRML documents. For example, a certain number of declarations will be required in any privacy policy that follows the Fair Information Practices.
A language without usage guidelines is difficult to use. The base declarations along with base objects create a framework for development of more rich and customized declarations.
Some examples of base objects are:
~ Role: Marketing role ~ Data Element: Customer email address ~ Data Element: Customer e;or~tact info ~ Purpose: Targeted marketing An example of base declaration is:
~ When a PRML document (data element) is modified (operation) (and thus a privacy policy changed) for any reason (purpose), all individuals that have consented to the current policy must be notified (action).
i4ssigning Declarations on Query Results In order to formalize some policy declarations one needs to refer to the aggregated data structures. It is conservable to specify a declaration that allows access to the aggregated data structure while prohibiting the access to the very data required to produce aggregated result.
Example: Air-miles points are collected for every transaction completed by the customer. The total number of points is not stored in the DB, but retrieved from the database as a sum of points in all transactions. The role 'customer representative' is allowed to read total number points. The same role isn't allowed to read details of individual transactions.
PRML currently does not support declarations on aggregated data structures.
E3in-size Declarations Some policy declarations allow a role full access to PII for the purpose of data mining with the condition that people do not run queries that identify an individual. Such declarations must constrain the number of records returned by a query.
Example: An archiving agent's goal is to populate a data warehouse with historical data on individuals. This role has access to an entire database (with the exception of individual's names), but isn't permitted to run queries that will uniquely identify individuals.
Integrating RDF with PRML
PRML is currently using a sub-set of the Resource Definition Framework (RDF) (http://www.w3c.org/RDF. The use of RDF may be extended to provide meta-data on the more granular level of PRML objects and declarations.
Extending the Roles Model The data model of PRML roles is not sufficiently expressive to allow formalizing a number of privacy policies. For example, no clean way to represent role delegation exists in the language.
UML to XML Mapping PRML is an XML application. Currently, the XML representation is defined in XML Document Type Definition (DTD) files. The XML representation is generated from the UML
drawings according to a set of rules derived from the Customer Profile Exchange (CPExchange) specification and are described in the remainder of this section.
Firstly, primitive data types are defined to indicate how #PCDATA values should be constrained to match the XML Schema data types. Some of these are the built-in data types defined by the XML
Scheme Datatypes standard. Others are PRML definitions of new XML Scheme generated data types.
The intent of the constraints imposed by each data type is either documented in this specification or referenced to in other standards. The XML 1.0 DTD cannot express the data type constraint; instead, the data type is represented with a parameter entity reference. For example:
<!-- Primitive Types: they match the XML Scheme Data Types -->
<!ENTITY % timeInstant "#PCDATA">
A class may be represented by two ENTITY definitions in the DTDs. One ENTITY
expresses the content of the class (if any), while the other ENTITY expresses programmatic attributes of the class (if any). Subclass entities include superclass entities. Data and relationships, which are the core of the language concepts, are expressed as the content of the relevant class and are represented by element ENTITY definitions. XML attributes, on the other hand, are used to express meta-data about the construct, or instructions to the tools, which must process the construct.
Where a class has member values, they are defined following the ENTfTY definitions for the contents of that class. For example:
<!-- Identifiable Mixin. Class -->
<!ENTITY % Identifiable " oid">
<!-- properties -->
<!ELEMENT oid (%key;)>
<!-- ExternalReference-Attr (describes classes with meta-data telling the tool to import data from an external resource -->
<!ENTITY % ExternalReference-Attrs " external-ref CDATA #IMPLIED">
<!-- Role Classes -->
<!ENTITY % Role-Set " role*">
<!ENTITY % Role-Set-Attrs " %ExternalReference-Attrs;, ...">
<!ELEMENT role-set (%Role-Set;)>
<!ATTLIST role-set (%Role-Set_Atars)>
<!ENTITY % Role " %Identifiable;, ...">
<!ELEMENT role (%Role;)>
hRML DTDs hrml-v1Ødtd <!--$Id: prml-vlØdt.d,v 1.9 2001/04%10 18:33:25 alexis Exp $
File: prml--vlØdtd Complete Privacy Rights Markup Language DTD Version 1 with all elements and entities defined in the standard.
PRML v1.0 DTD
__>
<!-- include all the PRML definitions -->
<!ENTITY % type-defs SYSTEM " prml-v1.0-types.dtd">
%type-defs;
<!ENTITY % support-de:fs SYSTEM " prml-v1.0-sup.dtd">
%support-defs;
<!ENTITY % role-defs SYSTEM " prml-v1.0-roles.dtd">
%role-defs;
<!ENTITY % operation-defs SYSTEM " prml-v1.0-ops.dtd">
%operation-defs;
<!ENTITY % purpose-defs SYSTEM " prml-v1.0-purpose.dtd">
%purpose-defs;
<!ENTITY % rdf-defs SYSTEM " prml-v1.0-rdf.dtd">
%rdf-defs;
<!ENTITY % data-defs SYSTEM " prml-v1.0-data.dtd">
%data-defs;
<!ENTITY % constraint-defs SYSTEM " prml-v1.0-constraint.dtd">
%constraint-defs;
<!ENTITY % transformation-defs SYSTEM " prml-v1.0-trans.dtd">
%transformation-defs;
<!ENTITY % action-defs SYSTEM " prml-v1.0-action.dtd">
%action-defs;
<!ENTITY % declaration-defs SYSTEM " prml-v1.0-decl.dtd">
%declaration-defs;
<!-- define root document element -->
<!ELEMENT prml (RDF, prml-import*, dictionary, data-schema, declaration-set)>
<!-- define dictionary element -->
<!ELEMENT dictionary (role-set, operation-set, purpose-set, data-set, constraint-set?, transformation-set?, action-set?)>
<!ENTITY % PrmlImportReference "' external-ref-location CDATA #REQUIRED">
<!ELEMENT prml-import: F:MPTY>
<!ATTLIST prml-import %PrmlImportReference; >
~prml-v1.0-rdf.dtd <!_-$Id: prml-v1.0-rdf.dtd,v 1.1 2001/03/09 14:24:11 alexis Exp $
This file defines t:he header of PRML document. RDF syntax is used to include document metadata. See htt.p://www.w3.org/RDF/ for more information.
__>
<!ELEMENT RDF (Description)>
<!ELEMENT Description (title?, creator?, date?, subject?)>
<!ELEMENT title (%string;)>
<!ELEMENT creator (%string;)>
<!ELEMENT date (%string;)>
<!ELEMENT subject (%str_ing;)>
~prml-v1.0-sup.dtd <!__ $Id: prml-v1.0-sup.dtd,v 1 6 2001/04/16 19:36:51 philippem Exp $
PRML supplemental definitions and declarations. Taken shamelessly from CPExchange.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elementa as desired. This file imposes no structure on the use of these elements.
__>
<!ENTITY % Identifiable " oid">
<!-- properties - .
<!ELEMENT oi~i (%key;)>
<!ENTITY % Named " name">
<!-- properties - ..
<!ELEMENT name (%string;)>
<!ENTITY % Labeled " label">
<!-- properties -<!ELEMENT label. (%string;)>
<!ENTITY % Describable " description?">
<!-- properties -<!ELEMENT description (%string;)>
<!ENTITY % ExtendsMul.tiple " extends?">
<!-- properties -<!ELEMENT extends (base--id+)>
<!ELEMENT base-id (%key;)>
<!ENTITY % Versionable " version?" >
<!-- properties - .
<!ELEMENT version (%string;)>
<!ENTITY % ExternalReference-Attrs " external-ref-location CDATA #IMPLIED">
<!ENTITY % TypeAttriY>ut:e " type CDATA #IMPLIED">
<!ENTITY % HasValue " value">
<!ELEMENT value (%string;) >
<!ATTLIST value %TypeAttribute; >
<!ENTITY % PropertyContainer " property-set?">
<!ELEMENT property-set (property*)>
<!ELEMENT property (%Named;, %HasValue;.l>
~prml-v1.0-types.dtd <!--$Id: prml-v1.0-typPS.dtd,v 1.2 2001/04/10 18:33:25 alexis Exp $
File: prml-v1.0-types.dtd Privacy Rights Markup Language DTD Version 1 Datatypes include file.
To use declare this file as an ENTITY and include it in the dtd that uses these definitions.
Borrowed from CPExchange -->
<!-- primitive XML Schema data types -->
<!ENTITY % real "#PCDATA">
<!ENTITY % Boolean "#PC'.DATA">
<!ENTITY % language "#F7CDATA">
<!-- RFC 1766 format -->
<!ENTITY % string "#PCDATA">
<!-- ISO 10646 unicode -->
<!ENTITY % uriReference "#PCDATA">
<!-- Uniform Resource Locator, IETF RFC 1738 -->
<!-- generated builtin XML Schema data types <!ENTITY % decimal " %real;">
<!ENTITY % integer " %decima:l;">
<!ENTITY % non-negative-integer " %integer;">
<!ENTITY % non-positi.ve:-integer " %integer;">
<!ENTITY % positive-i.nt.eger " %non-negative-integer;">
<!ENTITY % negative-integer " %non-positive-integer;">
<!ENTITY % mime " %st.r:i.ng;">
<!-- user defined types representing enumerated element values <!ENTITY % Enum "#PCDAT'A">
<!ENTITY % OpenEnum " %Enum;">
<!ENTITY % ClosedEnum " %Enum;">
<!ENTITY % CountryCodeEnum " %ClosedEnum;">
<!-- user defined simple data types -->
<!ENTITY % key " %string;">
<!-- string value is any supplier-specific object identifier -->
<!ENTITY % currencyValue " %string;">
<!-- format is a [ISO 3-character country code]:[decimal number] --->
<!ENTITY % ipAddress " %string;">
<!-- format is a either the dotted-decimal string or the complete tcp host.domain name - , <!ENTITY % numericPriority " %integer;">
<!-- format is an integer between 1 and 10, with 1 being the highest priority -->
<!-- property extensibility type -->
<!ENTITY % Property " %string;">
<!ENTITY % PropertyAtars " name CDATA #REQUIRED enumType CDATA #IMPLIED">
~prml-v1.0-data.dtd <!--$Id: prml-v1.0-data.dtd,v 1.5 2001./03/21 16:49:33 philippem Exp $
~~ 1 This file describes the high level constructs that make up a PRML data definition. It depends on the DTD files which define the basic and supplemental types. To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root., (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
-->
<!ENTITY % DataSet " data*">
<!ENTITY % Data " %Identifiable;, %Named;, %Describable;, label.-ref+">
<!ELEMENT data--set (%DataSet;) >
<!ELEMENT data (%Data;)>
<!-- To refer to a data element by its oid use the following element type -_>
<!ELEMENT data-idref (%key;) >
<!ELEMENT label-ref (%string;) >
<!ELEMENT data-struct.-ref (%string;) >
<!ELEMENT data-def (%Labeled;, %Named;, data-struct-ref+) >
<!ATTLIST data-def %TypeAttribute; >
<!ELEMENT data-struct (%Labeled;, %Named;, %Describable;) >
<!ELEMENT data-schema (data-def ~ data-struct)* >
~prml-v1.0-decl.dtd <!--$Id: prml-v1.0-decl.dtd,v 1.12 2001/04/11 20:50:22 philippem Exp $
This file describes the high level constructs that make up a PRML rule declaration. It depends on the DTD files which define the basic and supplemental types.
To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
_->
<!ENTITY % DeclarationSet " declaration*">
<!ENTITY % Declaration " %Identifiable;, name?, %Describable;, parent-declaration?, legislation-ref-location?, role-idref, operation-idref, purpose--idref, data-idref, transformation-specifier?, constraint-specifier-set?, action-~specifier-set?":.
<!ELEMENT declaration-set (%DeclarationSet;)>
<!ELEMENT declaration (%Declaration;)>
<!ELEMENT legislation-ref-location (%uriReference;)>
<!ELEMENT parent-declaration (%key;)>
prml-v1.0-roles.dtd <!-_ $Id: prml-v1.0-roles.dtd,v 1.3 2001/03/21 16:49:41 philippem Exp $
This file describes the high level constructs that make up a PRML role definition. It depends on the DTD files which define the basic and supplemental types. To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root., (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
_->
<!ENTITY % RoleSet " role*">
<!ENTITY % Role " %Identifiable;, %Named;, %Describable;, %ExtendsMultiple;">
<!ELEMENT role--set (%RoleSet;) >
<!ELEMENT role (%Role;)>
<!-- To refer to a role by its oid use the following element type -->
<!ELEMENT role-idref (%key;) >
~prml-v1.0-ops.dtd <!--$Id: prml-v1.0-ops.dtd,v 1.3 2001/03/21 16:49:37 philippem Exp $
This file describes the high level constructs that make up a PRML operation definition. It depends on the DTD files which define the basic and supplemental types.
To use this file, declare it: as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
-->
<!ENTITY % OperationSet " operation*">
<!ENTITY % Operation " %Identifiable;, %Named;, %Describable;, %ExtendsMultiple;, recipient-idref?">
<!ELEMENT recipient-idref (%key;)>
<!ELEMENT operation-set (%OperationSet;) >
<!ELEMENT operation (%Operation;)>
<!-- To refer to an operation by its oid use the following element type -->
<!ELEMENT operation-i.dref (%key;) >
prml-v1.0-purpose.dtd <!__ $Id: prml-v1.0-purpose.dtd,v 1.3 2001/03/21 16:49:39 philippem Exp $
This file describes the high level constructs that make up a PRML purpose definition. It depends on the DTD files which define the basic and supplemental types.
To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no stz-ucture on the use of these elements.
__>
<!ENTITY % PurposeSet " purpose*">
<!ENTITY % Purpose " %Identifiable;, %Named;, %DescribabLe;, %ExtendsMultiple;">
<!ELEMENT purpose-set (%PurposeSet;) >
<!ELEMENT purpose (%Purpose;)>
<!-- To refer to an operation by its oid use the following element type -->
<!ELEMENT purpose-idref (%key;) >
prml-v1.0-constraint.dtd <!__ $Id: prml-v1.0-constraint.dtd,v 1.6 2001/04/10 18:33:26 alexis Exp $
This file describes the high level constructs that make up a PRML
constraint definition. It depends on the DTD files which define the basic and supplemental types. To use this file, declare it as an ENTITY
and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
_->
<!ENTITY % ConstraintSet " constraint*">
<!ENTITY % Constraint °' %Identifiable;, %Named;, %Labeled;, %Describable;">
<!ELEMENT constraint-set (%ConstraintSet;) >
<!ELEMENT constraint (%Constraint;)>
<!-- Use HasConstrains when an element includes references to constraints -_>
<!ELEMENT constraint-specifier-set (constraint-specifier*)>
<!ELEMENT constraint-specifier (constraint-idref, %PropertyContainer;)>
<!-- To refer to an operation by its oid use the following element type -->
<!ELEMENT constraint-idref (%key;)>
i~rml-v1.0-action.dtd <!--$Id: prml-v1.0-acti.on.dtd,v 1.3 2001/04/11 20:50:20 philippem Exp $
This file describes the high level constructs that make up a PRML
action definition. It depends on t:he DTD files which define the basic and supplemental types. To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
__>
<!ENTITY % ActionSet " action*">
<!ENTITY % Action " %Identifiable;, %Named;, %Labeled;, %Describable;">
<!ELEMENT action-set (%ACtionSet;) >
<!ELEMENT action (%Action;)>
<!ELEMENT action-specifier-set (action-specifier*)>
<!ELEMENT action-specifier (action-idref, %PropertyContainer;)>
<!-- To refer to an action by its oid use the following element type -->
<!ELEMENT action-idref (%key;)>
SUMMARY OF THE INVENTION
Privacy Rights Markup Language (PRML) is the foundation for the solution to this problem.
PRML is an XML-based language that allows for the definition of objects-roles, operations, data elements, purposes, constraints, actions and transformations- and a mechanism for linking these objects together to form PRML privacy declarations. Declarations specify that a role can do an operation on a data element for a purpose if (optionally) certain constraints are satisfied. It can also optionally specify that an action should take place when this occurs and that the data element should be subject to a transformation before the operation can occur. A privacy policy is a collection of such PRML declarations.
The PRML standard offers a comprehensive set of constructs in order to represent privacy policies in full compliance with the Fair Information Practices (http://www.epic.or~~rivac~iconsumer/code; fair info.html).
PRML enables an organization to formalize its privacy policies and corresponding operational procedures. The language also enables the specification of policies around altering privacy policies.
Example: A PRML document may specify the following declaration: When a PRML
document is modified (and thus a privacy policy changed), all individuals that have consented to the current policy must be notified.
PRML is flexible to unambiguously define every possible privacy policy a corporation might wish to enforce.
PRML can be used in an auditing capacity. In this capacity, instead of interpreting a declaration as specifying that a role can do an operation on a data element for a purpose, it can be interpreted to specify that a role did an operation on a data element for a purpose.
A mechanism for document extension is specified. A single PRML file may not contain a full set of declarations or objects.
Example: One PRML file may contain the objects and declarations associated with the activities of the marketing department while another contains the objects and declarations associated with the activities of the customer care department.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Prior to an in depth specification of PRML objects and declarations, some examples may aid the reader.
~ An example of a role is: physician.
~ An example of an operation is: view.
~ An example of a purpose is: providing medical care.
~ An example of a data elerraent is: a patient's medical record containing the patient's name, address and medical condition.
~ An example of a constraint is: the physician is the patient's doctor.
~ An example of an action is: the patient must be notified via email when her record is accessed.
~ An example of a transforrnation is: the HIV test in the medical record should be replaced with "HIV test result not available".
~ An example of a declaration is: A physician can view a patient's medical records for the purpose of providing medical care if the physician is the patient's doctor. The patient should be notified via email when this occurs. The HIV test result in the medical condition should be replaced with "HIV test result not available" in this circumstance.
'terminology and Conventions ~ PRML Declaration: A statement that establishes a permissible relationship between PRML
objects.
~ PRML Object: .A role, operation, data element, purpose, constraint, action, or transformation.
PRML declarations refer to these objects and only these objects.
~ PRML File: An XML file containing a full or partial set of PRML object definitions and/or declarations.
~ PRML Document (Also referred as PRML policy): A PRMI_ file or collection of PRML files containing a comprehensive set of declarations and objects definitions.
~ UML Notation: The objects and attributes of a PRML policy document are described informally in this specification with Unified Modeling Language (LTML) static object model diagrams. The UML object diagrams capture the information and relationships, which are then represented in an XML format according to Document Type Definition (DTD) files. The UML class diagrams capture the object types (classes), their attributes, the attribute types, and the relationships between classes.
XML Notation: <Text i.n courier> is used to represent portions of an XML file.
F'RML Document Structure A PRML document is composed of four sections: the RI)F Header, the Object Dictionary, the Declaration Set, and the Data Schema.
RDF Header The Resource Definition Framework (RDF) specifies the file header. The header includes document meta-data information such as author, title, subject, and creation date.
C)bject Dictionary This section describes the contents of the object dictionary section of a PRML
file.
The purpose of the object dictionary is to define all objects that make up the declarations. All objects referenced in the set of declarations must be declared in the object dictionary. The dictionary includes exactly seven sets- one for each type of PRML object: <role-set>, <operation-set>, <purpose-set>, <data-set>, <constra:int-set>, <action-set>, and <transformation-set>.
Each set contains zero or more PRML objects of the corresponding type. Each set may refer to an external P RML file through the <external--ref-location> element.
The following diagram shows the data model of the PRML object dictionary:
PRML objects defined in the dictionary have several attributes. Every object has an Object ID (OID).
The OID must be unique within the class for each organization. This means that one corporation must not have two roles, for example, with the same OID. However, a role and a purpose may (but are never required to) share the same OID. PRML does not use the ID and IDREF
keywords as specified in the XML specification because the PRML, document may refer to objects residing in a different PRML file. All PRMI. objects also have human-readable names. All objects may optionally include a human-readable description.
Attributes of PRMI. Objects:
Element Description DatatypeApplicable i Objects oid A unique object ID- Key All must be unique among all objects within a class name Human readable name String All Description Human readable descriptionString All (optional) extends Reference of the oid(s)Key Roles, Purposes, of the base object (optional) and Operations label-ref Reference of the labelKey Data Elements of a <data-def > element in the <data--schema> section. (See section 0) recipient- Reference to the oid Key Operations of the role on idref the receiving end of this operation (typically used in the case of data sharing) (optional) label The label is assumed String Constraints, to refer to a function that implements Actions, and the constraint, action, Transformations or tranformation (optional) A description of attributes specific to certain. objects, and corresponding examples for each object type follow.
Stoles Examples of roles include 'customer care rep', 'customer care supervisor, and 'database administrator.' PRML does not include the concept of 'user'. Instead, all users play a particular role or roles at any given moment. PRML distinguishes users by their roles because privacy policies are created in terms of roles. A policy grants or prohibits (which is implied by not granting) access to a certain role, regardless of which specific user happens to be playing that role.
One role can extend multiple other roles. The fact that an role X extends role Y means that if a declaration exists that contains a reference to X, an implied declaration exists with a reference to Y.
For example, a child operation 'credit check' may extend a base operation 'read.' This means that if the operation 'credit check' is permissible, the base operation 'read' is also implied to be permissible.
'To extend an object, the <ext.ends> element of the child object should reference the base object.
Example:
<role-set>
<role>
<oid>ROLE-001</oid>
<name>CUSTOMER_CARE._REP</name>
<description>Customer care reps are users in the CS
department.</description>
</role>
<role>
<oid>ROLE-002</oi.d>
<name>CUSTOMER_CARE;_SUPERVISOR</name>
<description>Customer care supervisors are extensions of customer care reps.</description>
<extends>
<base-id>ROLE-U01</base-id>
</extends>
</role>
</role-set>
~Dperations Examples of operations include 'read'. 'update', 'delete', 'send email,' and 'send surfing profile to ad network.' Operations can define complex functions that require the combination of several atomic operations. Examples of non-atomic operations include 'send email,' and 'check credit.' The optional <recipient-idref> element is used to reference the recipient role for operations that share data with a particular role. A declaration may allow sharing of data only with a particular recipient.
Similar to roles, operations may form a hierarchy using the <extends> element.
Example:
<operation-set>
<operation>
<oid>OPERATION-ool</oid>
<name>Read</name>
</operation>
<operation>
<oid>OPERATION-002</oid>
<name>Send surfing profile to ad net~,vork</name>
<extends>
<base-id>OPERATION-001</base-id>
</extends>
<recipient-idref>ROLE-001</recipient-idref>
</operation>
</operation-set>
Purposes A Purpose object provides the context for performing same operation on some data. A declaration can indicate that an operation is permission only if the operation is executed for a specific purpose.
Simila to roles and operations, purposes may form a hierarchy using the <extends> element.
Example:
<purpose-set>
<purpose>
<oid>PURPOSE-001</oid>
<name>providing customer care</name>
<description />
</purpose>
</purpose-set>
Data Elements Data elements are objects that group various pieces of data as defined in the data schema. The decoupling of physical data location and declarations isolates the declarations from changes of the data location (e.g. changes to a database schema). When a database schema changes, declarations remain unchanged unless personal information is added or removed. For a description of how phyical data locations are represented, see section 0.
Example:
<data-set>
<data>
<oid>DATA-001</oid>
<name>email</name>
<label-ref>email</label-ref>
</data>
</data-set>
nonstraints All constraints referred to by a declaration must be satisfied for the operation to be considered permissible. A constraint in a PRML document contains a label. This label should refer to a function returning a Boolean value which is implemented by some application.
Example:
<constraint-set>
<constraint>
<oid>CONSTRAINT-007.</oid>
<name>Consent has been granted by the user referred to by the data element</name>
<label>OracleDB.StoredProcs.IsConsent</label>
</constraint>
</constraint-set>
A declaration can contain a reference to CONSTRAINT_001, to indicate that, for example, a role can perform an operation on a data element only if consent has been granted by the user referred to by the data element. The label 'OracleDB.StoredProcs.IsConsent' refers to a function that returns true if the declaration should be permissible and false c>therwise.
l~ransformations When a declaration refers to a data-access operation, an optional transformation object can be specified. Transformations control how the data should be changed prior to delivering it to the requesting user when the data access operation is granted. For example, a declaration can request the data be generalized before a particular role can read the data. As for constraints, the label is assumed to refer to a function that implements the transformation.
Example:
<transformation-set>
<transformation>
<oid>TRANFORMATION-001</oid>
<name>Remove HIV test results</name>
<label>OracleDB.StoredProcs.RemoveHIVResult</label>
</action>
</action-set>
/~Ct1o11S
Actions are procedures that should be executed whenever a declaration takes effect. As for constraints and transformations, the label is assumed to refer to a function that implements the action.
Example:
<action-set>
<action>
<oid>ACTION-001</oid>
<name>NOtify user' <name>
<label>OracleDB.~~toredProcs.SendEmail</label>
</action>
</action-set>
(Declaration Set A privacy policy consists of multiple PRML. declarations. Each declaration creates a permissible relationship between PRML objects as defined in the Object Dictionary. To build a set of all permissible relationships, the following algorithm is used:
~ By default, no relationships are permissible. No roles can do any operations on any data elements for any purpose.
~ If a declaration exists for a relationship, then that relationship is permissible.
A declaration object consists of the following elements:
Element Description Datatype oid A unique object ID- must be unique Key "-- among all declarations name Human readable name String description Human readable descriptionString (optional) role-idref Reference to an oid of Key a role object operation-idref ' Reference to an oid of Key an operation obj ect purpose-idref Reference to an oid of Key a purpose object data-idref Reference to an oid of Key a data object transformation-- ,A transformation and See diagram (optionally) specifier corresponding parameters.below The paramters are passed to the function that implements the transformation.
constraint-specifier-,A set of constraints See diagram and (optionally) set corresponding parameters.below The paramters are passed to the function that implements the constraint.
action-specifier-setA set of actions and (optionally)See diagram corresponding parameters.below The pararnters are passed to the function that implements the action.
Parent-declaration Reference of the oid of Key the parent declaration (used if this is an implicit declaration) (optional) i legislation-ref- The LIRI is the legislationUriReference that mandates location the existence if this declaration - -- (optional) -The three specified sets refer to an constraint. Action, and transformation objects within the dictionary and provide parameters. The parameters are not defined by this specification;
they are used by implementers of transformations, constraints, and actions to allow implementation re-use by multiple declarations.
The static diagram is as follows:
Example Declaration:
<declaration-set>
<declaration;>
<oid>DECLARATION-001</oid>
<name>purge-email</name>
<description>This declaration allows the purging of an email address.
<role-idref>ROLE-002</role-idref>
<operation-idref>OPERATION-001</operation-idref>
<purpose-idref>PiTRPOSE-002</purpose-idref>
<data-idref>DATA-001</data-idref>
<action-specifies-set>
<action-specifies>
<operation-idref>ACTION-004</operation-idref>
<prope.rty-set>
<property>
<name>pusge-email-address</name>
<value type="retention-calendar">30</value >
</prcperty>
</property-set>
</action-specifier>
</action-specifies-set>
</declaration>
</declaration-set>
I=xplicit and Implicit Declarations In the Object Dictionary, roles, operations, and purposes can be structured in a hierarchy using the <extents> relationship (see section 0). When a declaration contains a reference to an object X that has an <extents> relationship (the object X extends an object Y, for example), implicit declarations exist. The implicit declaration is a declaration that is identical to the original declaration with the exception that object Y replaces object X in the implied declaration. The implicit declarations may or may not explicitly appear in a PIUvIL file. However, if they do appear, the <parent-declaration>
element must appear and reference the original declaration. If the original declaration is subsequently deleted from the PRML file, the implied declaration must also be deleted.
For example, a PRML declaration 'customer-care-agent can send email to customer' uses operation 'send email'. This operation may extend operation °read'. In order to send email a user will need permission to read the customer's email address. So the explicit declaration above leads to the implicit declaration 'customer-care-agent can read email address.
Data Schema 'Che goal of data representation in PRML is to provide sufficient abstraction to eliminate the need to re-write declarations when the storage of data changes (e.g. a database data structure is modified), while providing the ability to reference a data element's exact location (e.g. a specific column in a database).
The following diagram demonstrates how data is represented and referenced:
<declaration-set>
<declaration>
<dictionary>
<data-set>
<data-set-id <data> -<role-:Ld> oid>
... label-ref>
:data-schexr~a>
<data-def:>
<label> ~"
<data-strut-ref>~
<data-stru~~t>~
<labels <name>
Declarations must contain a <data-set-id> element. The <data-set-id> element refers (via an <oid>) to a <data> element in the <data-set> of the <dictionary>. A <data>
element contains a <label-ref> element which references (via a <label>) a <data-def> element in the <data-schema>. An optional (or several optional} <data-struct-ref> elements) contained in a <data-def> element reference (via a <label>) a <data-struct> element which is contained in the <data-schema> element. The <data-struct> element contains a <name> element which identifies where the data is. The format of this description is not specified, but could be, for example, the "database.schema.table.column" tuple where the data is physically located.
Example:
<declaration-set>
<declaration>
<data-set-id>DATA-001</data-set-id>
</deolaration>
</declaration-set>
<dictionary>
<data-set import="dat:a-def.xml" »
<data>
<oid>DATA-001</oid>
<name>Customer Contact Info <label-ref>#cu:>tomer-contact-info</label-ref>
</data>
</data-set>
</dictionary>
The contents of the data-def.xml file:
<data-schema>
<data-def>
<label>customer-contact-info</label>
<data-struct-ref>#custEmailAddr</data-struct-ref>
<data-struct-ref>.#custName</data-struct-ref>
</data-def>
<data-struct>
<label>custName.firstName</label>
<name>OracleDB.CUST_INFO.CUST_TABLE.NAME</name>
</data-struct>
<data-struct>
<label>custName.lastName</label>
<name>OracleDB.CUST_INFO.CUST_TABLE.NAME</name>
</data-struct>
<data-struct>
<label>custEmailAddr</label>
<name>OracleDB.CL~ST_INFO.CUST_TABLE.EMAIL</name>
</data-struct>
<data-def>
<label>customer-surfing-profile<jlabel>
<data-struct-ref:.htap://someplace.com/schema#profile</data-struct-ref>
</data-def>
</data-schema>
~ A <data-def > element is not required to contain a <data-struct-ref >
element . If no <data-struct--ref> element exists, the data exists, but its description is unavailable or not required.
~ <data-set> elements can include the import--URI attribute which will indicate that the specified data is described in a <data-schema> element of the referenced document. It is recommended that Data Schemas be defined in a separate file, so this attribute should typically be present, but it is not required. If this attribute is not present, the PRML file must contain a <data-schema> that describes the <data> items.
~ There must be exactly one <data-set-id> per declaration.
~ When referencing a <data-def> or <data-struct> which is contained in the document, you must use the URI convention of placing, a hash ('#') character in front of the name. This character does not appear in the <name> element.
~ The <data-struct> elements describe the structure of various types of data elements. Note that different <data-def > elements can actually have the same structure simply by pointing to the same <data-struct> element(s). Each <data-struct> can optionally point to a local or remote <data-struct> that further defines the description of the data.
~ A <data-struct-ref> element can reference multiple <data-struct> elements.
The <data-struct-ref> string references all <data-struct> elements for which the <data-struct-ref>
string is aprefix of the <data-struct-ref> <label> element. The same logic applies to a <data> <label-ref> element and a <data-def> <label> element.
Conversion between PRML Data Schema and P3P
The following guidelines indicate the relationship and can be used to assist in the conversion from one format to the other. Familiarity with the P3P specification is assumed.
~ PRML data definitions provide a name and an optional description. There is no "short-description"
attribute, which can be specified so these are never generated when converting to a P3P data schema.
~ P3P data elements have an attribute "optional" while PRML does not. This attribute (defaulted to "no") indicates whether or not a visitor to a site can withhold the specified piece of data. When convening from PRML to f3P, this value should be explicitly set to "no." Since PRML deals with releasing data rather than collecting it, a visitor to the site should be obliged to provide it.
~ PRML does not define data categories. P3P can attach categories to DATA, DATA-DEF or DATA-STRUC'h elements in order to provide a hint regarding the intended use of the data. This must be specified somewhere inside a P3P data schema. One means is to use P3P's extension mechanism and assign the following for each DATA-DEF:
<CATEGORY><other-category>PRMh Data Schema</other-category></CATEGORIES>
~ The <data-set> element reaps directly to DATA-GROUP. <data-set> can specify an "import" attribute. This also maps directly to ''base". It is assumed that the PRML data-schema will always be in a separate file. In this case, the link to that file will be identified through a "base" attribute specified for the <DATA-GROUP> element. If the PRML data-schema is exported to the P3P file itself, the "base" attribute value must be set to the. empty string ("").
~ When converting PRML <data> elements to P3P <DATA> elements, the <name>
element must be converted to the attribute "ref'.
~ The <data-def > element maps to P3P's <DATA-DEF>. The <name> element becomes the "name" attribute. Similarly, the <name> element of a <struct-ref > element becomes a "structref' parameter. There is no equivalent to the "short-description"
attribute. Since this is optional in P3P, the conversion process does not specify it.
~ The PRML <data-struct> elements map to P3P~S <DATA-STRUCT> elements and are treated the same way as <data-def> elements.
~ Within PRML data definitions, instances of <description> elements become <horlG-DESCRIPTION> when transferred to P3P data schemas.
Examples- Privacy Policies Expressed in PRML
'The following examples are based on hypothetical, non-trivial privacy policies. Note that each privacy policy and correspondent PRML: document would be portions of a comprehensive set of policies.
:sample PRML Document A
The following policy is encoded in the PRML document below:
~ A customer care rep (role) may create (operation) an e-mail address (data element) in order to create an account (purpose). This email address must be deleted from the system no later than thirty (30) days after its creation (action). A customer care rep (role) may read (operation) a customer's email address (data element) in order to provide customer care (purpose) only if there is a pending transaction (constraint). A software module called an operations agent (role) may delete (purpose) the email address (data element] in order to satisfy the company's minimal retention policy (purpose).
<?xml version="1.0" ?>
<!DOCTYPE prml SYSTEM "prml-vl.U.dtd">
<prml>
<RDF xmlns:dc="http://purl.org/metadata/dublin core#">
<Description />
</RDF>
<dictionary>
<role-set>
<role>
<oid>ROLE-CUSTOMER-CARE-REP</oid>
<name>Customer care rep</name>
<description>Customer care representative. This role is assigned to all users of CRM system</description>
</role>
<role>
<oid>ROLE-OPERATIONS-AGENT</oid>
<name>OPERATIONS AGENT</name>
<description>A software module that assures that all data held in customer database respects minimal retention guidelines . </descript:ion>
</role>
</role-set>
<operation-set>
<operation>
<oid>OPERATION-DELETE</oid>
<name>delete</name>
<description /:.
</operation>
<operation>
<oid>OPERATION-CREATE</oid>
<name>create</name>
<description />
</operation>
<operation>
<oid>OPERATION-SEND-EMAIL</oid>
<name>Send Email<:/name>
<description>emai.l correspondence</description>
</operation>
</operation-set>
<purpose-set>
<purpose>
<oid>PURPOSE-MINIMAL-DATA-RETENTION</oid>
<name>minimal-data-retention</name>
</purpose>
<purpose>
<oid>PURPOSE-PROVIDE-CUST-CARE</oid>
<name>providing customer care</name>
</purpose>
<purpose>
<oid>PURPOSE-CREATE-ACCOUNT</oid>
<name>Create account</name>
</purpose>
</purpose-set>
<data-set>
<data>
<oid>DATA-EMAIL</oid>
<name>email</name>
<label-ref>#email</label-:ref>
</data>
</data-set>
<constraint-set>
<constraint>
<oid>CONSTRAINT-PENDING-TRANSACTION</oid>
<label>pending-transaction-exists</label>
<name>There is an pending transaction.</name>
</constraint>
</constraint~-set>
<transformation-set: />
<action-set>
<action>
<oid>ACTION-PURGE-EMAIL-ADDRESS-TIMER</oid>
<label>purge-emai.l-address-timer</label>
<name>purge-email.-address-timer</name>
</action>
</action-set>
</dictionary>
<data-schema>
<data-def>
<label>email</labe:l.>
<data-struct-ref>userdata.email</data-struct-ref>
</data-def>
<data-struct>
<label>userdata.email</label>
<name>OracleDB.schema.table.email</name>
</data-struct>
</data-schema>
<declaration-set>
<declaration>
<oid>DECL-1</oid>
<name>purge-email.</'name>
<role-idref.>ROLE-CUSTOMER-CARE-REP</role-idref>
<operation-idref>OF~ERATION-CREATE</operation-idref>
<purpose-idref>PURPOSE-CREATE-ACCOUNT</purpose-idref>
<data-idref>DATA-EMAIL</data-idref>
<action-specifies-~,et>
<action-specifier>
<operation-idref>ACTION-PURGE-EMAIL-ADDRESS-TIMER</operation-idref>
<property-set>
<property>
<name>purge-email-address</name>
<value type="retention-calendar">30</value >
</property>
</property-set>
</action-specifier>
</action-specifies-set>
</declaration>
<declaration>
<oid>DECL-2</oid>
<name>email-correspondance</name>
<role-idref>ROLE--CUSTOMER-CARE-REP</role-idref>
<operation-idref>OPERATION-SEND-EMAIL</operation-idref>
<purpose-idref>PiJRPOSE-PROVIDE-CLJST-CARE</purpose-idref>
<data-idref>DATA--EMAIL</data-idref>
<constraint-speci.fier-set>
<constraint-specifier>
<constraint-i,dref>CONSTRAINT-PENDING-TRANSACTION</constraint-idref>
<property-set:>
</property-set>
</constraint-specifier>
</constraint-spec:ifier-set>
</declaration>
<declaration>
<oid>DECL-3</oid>
<name>email-correspondance</name>
<role-idref>ROLE-OPERATIONS-AGENT</role-idref>
<operation-idref>OPERATION-DELETE</operation-idref>
<purpose-idref>PURf>OSE-MINIMAL-DATA-RETENTION</purpose-idref>
<data-idref>DATA-EMAIL</data-idref>
</declaration>
</declaration-set>
</prml>
:3ample PRML Document B
'The following policy is encoded in the PRML document below:
~ Marketing representatives (role) may send email (operation) in order to do targeted advertising (purpose).
Note the following implicit declaration also exists in the PRML document:
Marketing representatives (role) may read (operation) a customer's email addres (data) in order to do targeted advertising (purpose).
<?xml version="1.0" ?>
<!DOCTYPE prml SYSTEM "prml-vlØdtd">
<prml>
<RDF xmlns:dc="http://purl.org/metadata/dublin core#">
<Description />
</RDF>
<dictionary>
<role-set>
<role>
<oid>Role-1</oid>
<name>MARKETING_REPRESENTATIVE</name>
<description>Marketing representative. This role is responsible for communicating promotion campaigns</description>
</role>
</role-set>
<operation-set>
<operation:7 <oid>Operation-1</oid>
<name>Read</name>
</operation>
<operation:>
<oid>Operation-2</oid>
<name>Send Email</name>
<extends>
<base-.id>Operation-1</base-id>
</extends>
</operation>
</operation-set>
<purpose-set>
<purpose>
<oid>Purpose-1</oid>
<name>Targetted advertising</name>
</purpose>
</purpose-set>
<data-set>
<data>
<oid>Data-1</oid>
<name>Customer~s email address</name>
<label-ref>email-address</label-ref>
</data>
</data-set>
<constraint-set/>
<transformation-set />
<action-set />
</dictionary>
<data-schema>
<data-def>
<label>email-address</label>
<data-struct-ref>#userdata.email_address</data-struct-ref>
</data-def>
<data-struct>
<label>userdata.email address</label>
<name>OracleDB.userschema.userdata.email address</name>
</data-struct>
</data-schema>
<declaration-set>
<declaration>
<oid>Declaration-1<:/oid>
<name>Reading email address to provide targeted advertising</name>
<role-idref>ROle-1<:/role-idref>
<operation-idref>Operation-2</operation-idref>
<purpose-idref>Purpose-1</purpose-idref>
<data-idref>Data-1</data-idref>
</declaration>
</declaration-set>
</prml>
iCommonly Used Objects and Declarations A base set of commonly used objects and declarations will be provided to simplify the creation of PRML documents. For example, a certain number of declarations will be required in any privacy policy that follows the Fair Information Practices.
A language without usage guidelines is difficult to use. The base declarations along with base objects create a framework for development of more rich and customized declarations.
Some examples of base objects are:
~ Role: Marketing role ~ Data Element: Customer email address ~ Data Element: Customer e;or~tact info ~ Purpose: Targeted marketing An example of base declaration is:
~ When a PRML document (data element) is modified (operation) (and thus a privacy policy changed) for any reason (purpose), all individuals that have consented to the current policy must be notified (action).
i4ssigning Declarations on Query Results In order to formalize some policy declarations one needs to refer to the aggregated data structures. It is conservable to specify a declaration that allows access to the aggregated data structure while prohibiting the access to the very data required to produce aggregated result.
Example: Air-miles points are collected for every transaction completed by the customer. The total number of points is not stored in the DB, but retrieved from the database as a sum of points in all transactions. The role 'customer representative' is allowed to read total number points. The same role isn't allowed to read details of individual transactions.
PRML currently does not support declarations on aggregated data structures.
E3in-size Declarations Some policy declarations allow a role full access to PII for the purpose of data mining with the condition that people do not run queries that identify an individual. Such declarations must constrain the number of records returned by a query.
Example: An archiving agent's goal is to populate a data warehouse with historical data on individuals. This role has access to an entire database (with the exception of individual's names), but isn't permitted to run queries that will uniquely identify individuals.
Integrating RDF with PRML
PRML is currently using a sub-set of the Resource Definition Framework (RDF) (http://www.w3c.org/RDF. The use of RDF may be extended to provide meta-data on the more granular level of PRML objects and declarations.
Extending the Roles Model The data model of PRML roles is not sufficiently expressive to allow formalizing a number of privacy policies. For example, no clean way to represent role delegation exists in the language.
UML to XML Mapping PRML is an XML application. Currently, the XML representation is defined in XML Document Type Definition (DTD) files. The XML representation is generated from the UML
drawings according to a set of rules derived from the Customer Profile Exchange (CPExchange) specification and are described in the remainder of this section.
Firstly, primitive data types are defined to indicate how #PCDATA values should be constrained to match the XML Schema data types. Some of these are the built-in data types defined by the XML
Scheme Datatypes standard. Others are PRML definitions of new XML Scheme generated data types.
The intent of the constraints imposed by each data type is either documented in this specification or referenced to in other standards. The XML 1.0 DTD cannot express the data type constraint; instead, the data type is represented with a parameter entity reference. For example:
<!-- Primitive Types: they match the XML Scheme Data Types -->
<!ENTITY % timeInstant "#PCDATA">
A class may be represented by two ENTITY definitions in the DTDs. One ENTITY
expresses the content of the class (if any), while the other ENTITY expresses programmatic attributes of the class (if any). Subclass entities include superclass entities. Data and relationships, which are the core of the language concepts, are expressed as the content of the relevant class and are represented by element ENTITY definitions. XML attributes, on the other hand, are used to express meta-data about the construct, or instructions to the tools, which must process the construct.
Where a class has member values, they are defined following the ENTfTY definitions for the contents of that class. For example:
<!-- Identifiable Mixin. Class -->
<!ENTITY % Identifiable " oid">
<!-- properties -->
<!ELEMENT oid (%key;)>
<!-- ExternalReference-Attr (describes classes with meta-data telling the tool to import data from an external resource -->
<!ENTITY % ExternalReference-Attrs " external-ref CDATA #IMPLIED">
<!-- Role Classes -->
<!ENTITY % Role-Set " role*">
<!ENTITY % Role-Set-Attrs " %ExternalReference-Attrs;, ...">
<!ELEMENT role-set (%Role-Set;)>
<!ATTLIST role-set (%Role-Set_Atars)>
<!ENTITY % Role " %Identifiable;, ...">
<!ELEMENT role (%Role;)>
hRML DTDs hrml-v1Ødtd <!--$Id: prml-vlØdt.d,v 1.9 2001/04%10 18:33:25 alexis Exp $
File: prml--vlØdtd Complete Privacy Rights Markup Language DTD Version 1 with all elements and entities defined in the standard.
PRML v1.0 DTD
__>
<!-- include all the PRML definitions -->
<!ENTITY % type-defs SYSTEM " prml-v1.0-types.dtd">
%type-defs;
<!ENTITY % support-de:fs SYSTEM " prml-v1.0-sup.dtd">
%support-defs;
<!ENTITY % role-defs SYSTEM " prml-v1.0-roles.dtd">
%role-defs;
<!ENTITY % operation-defs SYSTEM " prml-v1.0-ops.dtd">
%operation-defs;
<!ENTITY % purpose-defs SYSTEM " prml-v1.0-purpose.dtd">
%purpose-defs;
<!ENTITY % rdf-defs SYSTEM " prml-v1.0-rdf.dtd">
%rdf-defs;
<!ENTITY % data-defs SYSTEM " prml-v1.0-data.dtd">
%data-defs;
<!ENTITY % constraint-defs SYSTEM " prml-v1.0-constraint.dtd">
%constraint-defs;
<!ENTITY % transformation-defs SYSTEM " prml-v1.0-trans.dtd">
%transformation-defs;
<!ENTITY % action-defs SYSTEM " prml-v1.0-action.dtd">
%action-defs;
<!ENTITY % declaration-defs SYSTEM " prml-v1.0-decl.dtd">
%declaration-defs;
<!-- define root document element -->
<!ELEMENT prml (RDF, prml-import*, dictionary, data-schema, declaration-set)>
<!-- define dictionary element -->
<!ELEMENT dictionary (role-set, operation-set, purpose-set, data-set, constraint-set?, transformation-set?, action-set?)>
<!ENTITY % PrmlImportReference "' external-ref-location CDATA #REQUIRED">
<!ELEMENT prml-import: F:MPTY>
<!ATTLIST prml-import %PrmlImportReference; >
~prml-v1.0-rdf.dtd <!_-$Id: prml-v1.0-rdf.dtd,v 1.1 2001/03/09 14:24:11 alexis Exp $
This file defines t:he header of PRML document. RDF syntax is used to include document metadata. See htt.p://www.w3.org/RDF/ for more information.
__>
<!ELEMENT RDF (Description)>
<!ELEMENT Description (title?, creator?, date?, subject?)>
<!ELEMENT title (%string;)>
<!ELEMENT creator (%string;)>
<!ELEMENT date (%string;)>
<!ELEMENT subject (%str_ing;)>
~prml-v1.0-sup.dtd <!__ $Id: prml-v1.0-sup.dtd,v 1 6 2001/04/16 19:36:51 philippem Exp $
PRML supplemental definitions and declarations. Taken shamelessly from CPExchange.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elementa as desired. This file imposes no structure on the use of these elements.
__>
<!ENTITY % Identifiable " oid">
<!-- properties - .
<!ELEMENT oi~i (%key;)>
<!ENTITY % Named " name">
<!-- properties - ..
<!ELEMENT name (%string;)>
<!ENTITY % Labeled " label">
<!-- properties -<!ELEMENT label. (%string;)>
<!ENTITY % Describable " description?">
<!-- properties -<!ELEMENT description (%string;)>
<!ENTITY % ExtendsMul.tiple " extends?">
<!-- properties -<!ELEMENT extends (base--id+)>
<!ELEMENT base-id (%key;)>
<!ENTITY % Versionable " version?" >
<!-- properties - .
<!ELEMENT version (%string;)>
<!ENTITY % ExternalReference-Attrs " external-ref-location CDATA #IMPLIED">
<!ENTITY % TypeAttriY>ut:e " type CDATA #IMPLIED">
<!ENTITY % HasValue " value">
<!ELEMENT value (%string;) >
<!ATTLIST value %TypeAttribute; >
<!ENTITY % PropertyContainer " property-set?">
<!ELEMENT property-set (property*)>
<!ELEMENT property (%Named;, %HasValue;.l>
~prml-v1.0-types.dtd <!--$Id: prml-v1.0-typPS.dtd,v 1.2 2001/04/10 18:33:25 alexis Exp $
File: prml-v1.0-types.dtd Privacy Rights Markup Language DTD Version 1 Datatypes include file.
To use declare this file as an ENTITY and include it in the dtd that uses these definitions.
Borrowed from CPExchange -->
<!-- primitive XML Schema data types -->
<!ENTITY % real "#PCDATA">
<!ENTITY % Boolean "#PC'.DATA">
<!ENTITY % language "#F7CDATA">
<!-- RFC 1766 format -->
<!ENTITY % string "#PCDATA">
<!-- ISO 10646 unicode -->
<!ENTITY % uriReference "#PCDATA">
<!-- Uniform Resource Locator, IETF RFC 1738 -->
<!-- generated builtin XML Schema data types <!ENTITY % decimal " %real;">
<!ENTITY % integer " %decima:l;">
<!ENTITY % non-negative-integer " %integer;">
<!ENTITY % non-positi.ve:-integer " %integer;">
<!ENTITY % positive-i.nt.eger " %non-negative-integer;">
<!ENTITY % negative-integer " %non-positive-integer;">
<!ENTITY % mime " %st.r:i.ng;">
<!-- user defined types representing enumerated element values <!ENTITY % Enum "#PCDAT'A">
<!ENTITY % OpenEnum " %Enum;">
<!ENTITY % ClosedEnum " %Enum;">
<!ENTITY % CountryCodeEnum " %ClosedEnum;">
<!-- user defined simple data types -->
<!ENTITY % key " %string;">
<!-- string value is any supplier-specific object identifier -->
<!ENTITY % currencyValue " %string;">
<!-- format is a [ISO 3-character country code]:[decimal number] --->
<!ENTITY % ipAddress " %string;">
<!-- format is a either the dotted-decimal string or the complete tcp host.domain name - , <!ENTITY % numericPriority " %integer;">
<!-- format is an integer between 1 and 10, with 1 being the highest priority -->
<!-- property extensibility type -->
<!ENTITY % Property " %string;">
<!ENTITY % PropertyAtars " name CDATA #REQUIRED enumType CDATA #IMPLIED">
~prml-v1.0-data.dtd <!--$Id: prml-v1.0-data.dtd,v 1.5 2001./03/21 16:49:33 philippem Exp $
~~ 1 This file describes the high level constructs that make up a PRML data definition. It depends on the DTD files which define the basic and supplemental types. To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root., (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
-->
<!ENTITY % DataSet " data*">
<!ENTITY % Data " %Identifiable;, %Named;, %Describable;, label.-ref+">
<!ELEMENT data--set (%DataSet;) >
<!ELEMENT data (%Data;)>
<!-- To refer to a data element by its oid use the following element type -_>
<!ELEMENT data-idref (%key;) >
<!ELEMENT label-ref (%string;) >
<!ELEMENT data-struct.-ref (%string;) >
<!ELEMENT data-def (%Labeled;, %Named;, data-struct-ref+) >
<!ATTLIST data-def %TypeAttribute; >
<!ELEMENT data-struct (%Labeled;, %Named;, %Describable;) >
<!ELEMENT data-schema (data-def ~ data-struct)* >
~prml-v1.0-decl.dtd <!--$Id: prml-v1.0-decl.dtd,v 1.12 2001/04/11 20:50:22 philippem Exp $
This file describes the high level constructs that make up a PRML rule declaration. It depends on the DTD files which define the basic and supplemental types.
To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
_->
<!ENTITY % DeclarationSet " declaration*">
<!ENTITY % Declaration " %Identifiable;, name?, %Describable;, parent-declaration?, legislation-ref-location?, role-idref, operation-idref, purpose--idref, data-idref, transformation-specifier?, constraint-specifier-set?, action-~specifier-set?":.
<!ELEMENT declaration-set (%DeclarationSet;)>
<!ELEMENT declaration (%Declaration;)>
<!ELEMENT legislation-ref-location (%uriReference;)>
<!ELEMENT parent-declaration (%key;)>
prml-v1.0-roles.dtd <!-_ $Id: prml-v1.0-roles.dtd,v 1.3 2001/03/21 16:49:41 philippem Exp $
This file describes the high level constructs that make up a PRML role definition. It depends on the DTD files which define the basic and supplemental types. To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root., (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
_->
<!ENTITY % RoleSet " role*">
<!ENTITY % Role " %Identifiable;, %Named;, %Describable;, %ExtendsMultiple;">
<!ELEMENT role--set (%RoleSet;) >
<!ELEMENT role (%Role;)>
<!-- To refer to a role by its oid use the following element type -->
<!ELEMENT role-idref (%key;) >
~prml-v1.0-ops.dtd <!--$Id: prml-v1.0-ops.dtd,v 1.3 2001/03/21 16:49:37 philippem Exp $
This file describes the high level constructs that make up a PRML operation definition. It depends on the DTD files which define the basic and supplemental types.
To use this file, declare it: as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
-->
<!ENTITY % OperationSet " operation*">
<!ENTITY % Operation " %Identifiable;, %Named;, %Describable;, %ExtendsMultiple;, recipient-idref?">
<!ELEMENT recipient-idref (%key;)>
<!ELEMENT operation-set (%OperationSet;) >
<!ELEMENT operation (%Operation;)>
<!-- To refer to an operation by its oid use the following element type -->
<!ELEMENT operation-i.dref (%key;) >
prml-v1.0-purpose.dtd <!__ $Id: prml-v1.0-purpose.dtd,v 1.3 2001/03/21 16:49:39 philippem Exp $
This file describes the high level constructs that make up a PRML purpose definition. It depends on the DTD files which define the basic and supplemental types.
To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no stz-ucture on the use of these elements.
__>
<!ENTITY % PurposeSet " purpose*">
<!ENTITY % Purpose " %Identifiable;, %Named;, %DescribabLe;, %ExtendsMultiple;">
<!ELEMENT purpose-set (%PurposeSet;) >
<!ELEMENT purpose (%Purpose;)>
<!-- To refer to an operation by its oid use the following element type -->
<!ELEMENT purpose-idref (%key;) >
prml-v1.0-constraint.dtd <!__ $Id: prml-v1.0-constraint.dtd,v 1.6 2001/04/10 18:33:26 alexis Exp $
This file describes the high level constructs that make up a PRML
constraint definition. It depends on the DTD files which define the basic and supplemental types. To use this file, declare it as an ENTITY
and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
_->
<!ENTITY % ConstraintSet " constraint*">
<!ENTITY % Constraint °' %Identifiable;, %Named;, %Labeled;, %Describable;">
<!ELEMENT constraint-set (%ConstraintSet;) >
<!ELEMENT constraint (%Constraint;)>
<!-- Use HasConstrains when an element includes references to constraints -_>
<!ELEMENT constraint-specifier-set (constraint-specifier*)>
<!ELEMENT constraint-specifier (constraint-idref, %PropertyContainer;)>
<!-- To refer to an operation by its oid use the following element type -->
<!ELEMENT constraint-idref (%key;)>
i~rml-v1.0-action.dtd <!--$Id: prml-v1.0-acti.on.dtd,v 1.3 2001/04/11 20:50:20 philippem Exp $
This file describes the high level constructs that make up a PRML
action definition. It depends on t:he DTD files which define the basic and supplemental types. To use this file, declare it as an ENTITY and include it.
To incorporate the elements in this file into a higher level document structure, the root, (or some other) element of the new document should include the elements as desired. This file imposes no structure on the use of these elements.
__>
<!ENTITY % ActionSet " action*">
<!ENTITY % Action " %Identifiable;, %Named;, %Labeled;, %Describable;">
<!ELEMENT action-set (%ACtionSet;) >
<!ELEMENT action (%Action;)>
<!ELEMENT action-specifier-set (action-specifier*)>
<!ELEMENT action-specifier (action-idref, %PropertyContainer;)>
<!-- To refer to an action by its oid use the following element type -->
<!ELEMENT action-idref (%key;)>
Claims
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002351696A CA2351696A1 (en) | 2001-06-26 | 2001-06-26 | System for implementing privacy policies written using a markup language |
| PCT/CA2002/000983 WO2003001402A2 (en) | 2001-06-26 | 2002-06-26 | System for implementing privacy policies written using a markup language |
| CA002491090A CA2491090A1 (en) | 2001-06-26 | 2002-06-26 | System for implementing privacy policies written using a markup language |
| AU2002312692A AU2002312692A1 (en) | 2001-06-26 | 2002-06-26 | System for implementing privacy policies written using a markup language |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002351696A CA2351696A1 (en) | 2001-06-26 | 2001-06-26 | System for implementing privacy policies written using a markup language |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2351696A1 true CA2351696A1 (en) | 2002-12-26 |
Family
ID=4169350
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002351696A Abandoned CA2351696A1 (en) | 2001-06-26 | 2001-06-26 | System for implementing privacy policies written using a markup language |
Country Status (3)
| Country | Link |
|---|---|
| AU (1) | AU2002312692A1 (en) |
| CA (1) | CA2351696A1 (en) |
| WO (1) | WO2003001402A2 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9727751B2 (en) | 2010-10-29 | 2017-08-08 | Nokia Technologies Oy | Method and apparatus for applying privacy policies to structured data |
-
2001
- 2001-06-26 CA CA002351696A patent/CA2351696A1/en not_active Abandoned
-
2002
- 2002-06-26 WO PCT/CA2002/000983 patent/WO2003001402A2/en not_active Application Discontinuation
- 2002-06-26 AU AU2002312692A patent/AU2002312692A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| AU2002312692A1 (en) | 2003-01-08 |
| WO2003001402A2 (en) | 2003-01-03 |
| WO2003001402A3 (en) | 2003-12-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7599947B1 (en) | Method and system for converting hierarchical database schemas into relational database schemas | |
| Conrad et al. | XML conceptual modeling using UML | |
| US7788238B2 (en) | Extensible object-modelling mechanism | |
| KR101224670B1 (en) | Platform for data services across disparate application frameworks | |
| World Wide Web Consortium | Document object model (DOM) level 3 core specification | |
| CA2343263A1 (en) | Privacy framework | |
| US20030028540A1 (en) | Web-based architecture | |
| US20020156811A1 (en) | System and method for converting an XML data structure into a relational database | |
| US20050080808A1 (en) | Document creation system and method using knowledge base, precedence, and integrated rules | |
| Rys | Bringing the Internet to your database: Using SQL Server 2000 and XML to build loosely-coupled systems | |
| Xiao et al. | Modeling and transformation of object-oriented conceptual models into XML schema | |
| Vorthmann et al. | Beyond schemas. | |
| WO2008130768A1 (en) | Describing expected entity relationships in a model | |
| Boldyreff et al. | Active artefact management for distributed software engineering | |
| Skogan | UML as a schema language for XML based data interchange | |
| Grundy et al. | Generating edi message translations from visual specifications | |
| Balamurugan et al. | Performance Evaluation of Native XML database and XML Enabled database | |
| Pal et al. | XML support in Microsoft SQL Server 2005 | |
| Rose et al. | Virtual XML: A toolbox and use cases for the XML world view | |
| CA2351696A1 (en) | System for implementing privacy policies written using a markup language | |
| Song et al. | Repox: An xml repository for workflow designs and specifications | |
| Bernauer et al. | Representing xml schema in uml-an uml profile for xml schema | |
| Coles | Pro SQL Server 2008 XML | |
| Whitehead Jr et al. | The WebDAV property design | |
| Menet et al. | Managing master data with XML schema and UML |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued | ||
| FZDE | Discontinued |
Effective date: 20040324 |