text:
Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
PROV-DM, the PROV data model, is a data model for provenance that describes the entities, people and activities involved in producing a piece of data or thing. PROV-DM is structured in six components, dealing with: (1) entities and activities, and the time at which they were created, used, or ended; (2) agents bearing responsibility for entities that were generated and actities that happened; (3) derivations between entities; (4) properties to link entities that refer to a same thing; (5) collections of entities, whose provenance can itself be tracked; (6) a simple annotation mechanism.
This document introduces the provenance concepts underpinning PROV-DM in natural language, and systematically defines PROV-DM types and relations. PROV data model is domain-agnostic, but is equipped with extensibility points allow domain-specific information to be included.
Two further documents complete the specification of PROV-DM. First, a companion document specifies the set of constraints that well-structured provenance descriptions should follow; these provide an interpretation for provenance descriptions. Second, to be able to provide examples of provenance, a notation is used for expressing instances of PROV-DM for human consumption; the syntactic details of this notation are also kept in a separate document.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the fourth public release of the PROV-DM document. Following feedback, the Working Group has decided to reorganize this document substantially, separating the data model, from its contraints, and the notation used to illustrate it. The PROV-DM release is synchronized with the release of the PROV-O, PROV-PRIMER, PROV-N, PROV-DM-CONSTRAINTS documents. We are now making clear what the entry path to the PROV family of specifications is.
This document was published by the Provenance Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to email@example.com (subscribe, archives). All feedback is welcome.
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
For the purpose of this specification, provenance is defined as a record that describes the people, institutions, entities, and activities involved in producing, influencing, or delivering a piece of data or a thing. In particular, the provenance of information is crucial in deciding whether information is to be trusted, how it should be integrated with other diverse information sources, and how to give credit to its originators when reusing it. In an open and inclusive environment such as the Web, where users find information that is often contradictory or questionable, provenance can help those users to make trust judgements.
The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems. Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.
Thus, the vision is that different provenance-aware systems natively adopt their own model for representing their provenance, but a core provenance data model can be readily adopted as a provenance interchange model across such systems.
A set of specifications, referred to as the PROV family of specifications, define the various aspects that are necessary to achieve this vision in an interoperable way:
PROV-DM is a domain-agnostic model, but with clear extensibility points allowing further domain-specific and application-specific extensions to be defined. The PROV data model is structured according to six components covering various aspects of provenance:
This specification intentionally presents the key concepts of the PROV Data Model, without drilling down into all its subtleties. Using these key concepts, it becomes possible to write useful provenance descriptions very quickly, and publish or embed them along side the data they relate to.
However, if data changes, then it is challenging to express its provenance precisely, like it would be for any other form of metadata. To address this challenge, a refinement is proposed to enrich simple provenance, with extra-descriptions that help qualify the specific subject of provenance and provenance itself, with attributes and temporal interval, intended to satisfy a comprehensive set of constraints. These aspects are covered in the companion specification [PROV-DM-CONSTRAINTS].
Section 2 provides starting points for the PROV Data Model, listing a set of types and relations, which are allows users to make initial provenance descriptions.
Section 3 illustrates how PROV-DM can be used to express the provenance of a report published on the Web.
Section 4 provides the definition of PROV-DM concepts, structured according to six components.
Section 5 summarizes PROV-DM extensibility points.
Section 6 introduces the idea that constraints can be applied to the PROV data model to refine provenance descriptions; these are covered in the companion specification [PROV-DM-CONSTRAINTS].
The PROV namespace is http://www.w3.org/ns/prov#.
All the concepts, reserved names and attributes introduced in this specification belong to the PROV namespace.
The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in [RFC2119].
This section provides an introduction to the PROV data model by overviewing a set of concepts underpinning provenance descriptions that a novice reader would write in a first instance. In Sections 2.1 to 2.4, these concepts are described in natural language and illustrated by small examples. Since PROV-DM is a conceptual data model, Section 2.5 maps the concepts to various types and relations, which are illustrated graphically in a simplified UML diagram. Section 2.6 then summarizes the PROV notation allowing instances of PROV-DM to be written down.
Things we want to describe the provenance of are called entities in PROV. The term "things" encompasses a broad diversity of notions, including digital objects such as a file or web page, physical things such as a building or a printed book, or a car as well as abstract concepts and ideas. One can regard any Web resource as an example of Entity in this context.
An entity may be the document at URI http://www.w3.org/TR/prov-dm/, a file in a file system, a car, or an idea.
An activity is something that occurs over a period of time and acts upon or with entities. This action can take multiple forms: consuming, processing, transforming, modifying, relocating, using, generating, or being associated with entities. Activities that operate on digital entities may for example move, copy, or duplicate them.
An activity may be the publishing of a document on the Web, sending a twitter message, extracting metadata embedded in a file, driving a car from Boston to Cambridge, assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news items according to some criteria, running a SPARQL query over a triple store, and editing a file.
Activities and entities are associated with each other in two different ways: activities are consumers of entities and activities are producers of entities. The act of producing or consuming an entity may have a duration. The term 'generation' refers to the completion of the the act of producing; likewise, the term 'usage' refers to the beginning of the act of consuming entities. Thus, we define the following notions of generation and usage.
Examples of generation are the completed creation of a file by a program, the completed creation of a linked data set, and the completed publication of a new version of a document.
Usage examples include a procedure beginning to consume an argument, a service starting to read a value on a port, a program beginning to read a configuration file, or the point at which an ingredient, such as eggs, is being added in a baking activity. Usage may entirely consume an entity (e.g. eggs are no longer available after being added to the mix); alternatively, a same entity may be used multiple times, possibly by different activities (e.g. a file on a file system can be read indefinitely).
Activities are consumers of entities and producers of entities. In some case, the consumption of an entity influences the creation of another in some way. This notion is captured by derivations, defined as follows.
A derivation is a transformation of an entity into another, a construction of an entity into another, or an update of an entity, resulting in a new one.
Examples of derivation include the transformation of a relational table into a linked data set, the transformation of a canvas into a painting, the transportation of a work of art from London to New York, and a physical transformation such as the melting of ice into water.
The motivation for introducing agents in the model is to denote the agent's responsibility for activities.
An agent is a type of entity that bears some form of responsibility for an activity taking place.
The definition of agent intentionally stays away from using concepts such as enabling, causing, initiating, triggering, affecting, etc, because many entities also enable, cause, initiate, and affect in some way the activities. Concepts such as triggers are themselves defined in relations between entities and activities. So the notion of having some degree of responsibility is really what makes an agent.
An agent is a particular type of Entity. This means that the model can be used to express provenance of the agents themselves.
Software for checking the use of grammar in a document may be defined as an agent of a document preparation activity, and at the same time one can describe its provenance, including for instance the vendor and the version history.
There are some useful types of entities and agents that are commonly encountered in applications making data and documents available on the Web; we introduce them in the rest of this section.
A plan is an entity that represents a set of actions or steps intended by one or more agents to achieve some goals. There exist no prescriptive requirement on the nature of plans, their representation, the actions or steps they consist of, or their intended goals. Since plans may evolve over time, it may become necessary to track their provenance, so plans themselves are entities. Representing the plan explicitly in the provenance can be useful for various tasks: for example, to validate the execution as represented in the provenance record, to manage expectation failures, or to provide explanations.
A plan can be a blog post tutorial for how to set up a web server, a list of instructions for a micro-processor execution, a cook's written recipe for a chocolate cake, or a workflow for a scientific experiment.
Three types of agents are recognized because they are commonly encountered in applications making data and documents available on the Web: persons, software agents, and organizations.
A Web site and service selling books on the Web and the company hosting them are software agents and organizations, respectively.
A collection is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be member of the collections. This concept allows for the provenance of the collection, but also of its constituents to be expressed. Such a notion of collection corresponds to a wide variety of concrete data structures, such as a maps, dictionaries, or associative arrays.
An example of collection is an archive of documents. Each document has its own provenance, but the archive itself also has some provenance: who maintained it, which documents it contained at which point in time, how it was assembled, etc.
An account is an entity that contains a bundle of provenance descriptions. Making an account an entity allows for provenance of provenance to be expressed.
For users to decide whether they can place their trust in a resource, they may want to analyze the resource's provenance, but also determine who its provenance is attributed to, and when it was generated. In other words, users need to be able to determine the provenance of provenance. Hence, provenance is also regarded as an entity (of type Account), by which provenance of provenance can then be expressed.
Agents can be related to entities, activities, and other agents.
A blog post can be attributed to an author, a mobile phone to its manufacturer.
Agents are defined as having some kind of responsibility for activities. However, one may want to be more specific about the nature of an agent's responsibility. For example, a programmer and a researcher could both be associated with running a workflow, but it may not matter which programmer clicked the button to start the workflow while it would matter a lot which researcher told the programmer to do so.
Furthermore, provenance reflects activities that have occurred. In some cases, those activities reflect the execution of a plan that was designed in advance to guide the execution. A plan may be associated to an activity, which represents what was intended to happen.
An activity association is an assignment of responsibility to an agent for an activity, indicating that the agent had a role in the activity. It further allows for a plan to be specified, which is the plan intended by the agent to achieve some goals in the context of this activity.
Examples of association between an activity and an agent are:
Responsibility is the fact that an agent is accountable for the actions of a "subordinate" agent, in the context of an activity. The nature of this relation is intended to be broad, including delegation or contractual relation.
A student publishing a web page describing an academic department could result in both the student and the department being agents associated with the activity, and it may not matter which student published a web page but it matters a lot that the department told the student to put up the web page.
So far, we have introduced a series of concepts underpinning provenance. PROV-DM is a conceptual data model consisting of types and relations between these. Table (Mapping of Provenance concepts to types and relations in PROV-DM) shows how provenance concepts can be mapped to types and relations in PROV-DM: the first column lists concepts introduced in this section, the second column indicates whether a concept maps to a type or a relation, whereas the third column contains the corresponding name. We note that names of relations have a verbal form in the past tense to express what happened in the past, as opposed to what may or will happen.
Provenance Concepts | PROV-DM types or relations | |
Entity | Types in PROV-DM | entity |
Activity | activity | |
Agent | agent | |
Generation | Relations in PROV-DM | wasGeneratedBy |
Usage | used | |
Attribution | wasAttributedTo | |
Association | wasAssociatedWith | |
Responsibility | actedOnBehalfOf | |
Derivation | wasDerivedFrom |
Figure overview-types-and-relations illustrates the three types (entity, activity, and agent) and how they relate to each other. At this stage, all relations are shown to be binary. When examining PROV-DM in details, some relations, while involving two primary elements, are shown to be n-ary.
Figure overview-types-and-relations is not intended to be complete. It only illustrates types and relations from Section starting-points and exploited in the example discussed in the next section. They will then be explained in detail in Section data-model-components. The third column of Table (Mapping of Provenance concepts to types and relations in PROV-DM) lists names that are part of a textual notation to write instances of the PROV-DM data model. This notation, referred to as the PROV-N notation, is outlined in the next section.
A key goal of PROV-DM is the specification of a machine-processable data model for provenance so that applications can retrieve provenance and reason about it. As such, representations of PROV-DM are available in RDF and XML.
However, it is important to provide instances of provenance for human consumption, as in this document or elsewhere. To this end, PROV-N is a notation that is designed to write instances of the PROV-DM data model in a compact textual form, without the syntactic baggage and constraints coming with a markup language such as XML or a description framework such as RDF. We outline here some of its key design principles. For full details, the reader is referred to the companion specification [PROV-N].
PROV-N optional arguments need not be specified. For cases where it is desirable to indicate which arguments have not been specified, PROV-N uses the syntactic marker - for unspecified arguments.
Most expressions have an identifier which always occur in first position, and an optional set of attribute-value pairs, which occur in last position, and delimited by square brackets.
An activity with identifier a1 and an attribute type with value createFile.
activity(a1, [prov:type="createFile"])Two entities with identifiers e1 and e2.
entity(e1) entity(e2)The activity a1 used e1, and e2 was generated by a1.
used(a1,e1) wasGeneratedBy(e2,a1)
Section starting-points has introduced some provenance concepts, and how they are expressed as types or relations in the PROV data model. The purpose of this section is to put these concepts into practice in order to express the provenance of some document published on the Web. With this realistic example, PROV-DM constructs are composed together, and a graphical illustration shows a provenance description forming a directed graph, rooted at the entity we want to explain the provenance of, and pointing to the entities, activities, and agents it depended on. This example also shows that, sometimes, multiple provenance descriptions about a same entity can co-exist, which then justifies the need for provenance of provenance.
The World Wide Web Consortium publishes many technical reports. In this example, we consider a technical report, and describe its provenance. Specifically, we consider the second version of the PROV-DM document http://www.w3.org/TR/2011/WD-prov-dm-20111215. Its provenance can be expressed from several perspectives, which we present. In the first one, provenance is concerned with the W3C process, whereas in the second one, it takes the authors' viewpoint; we then provide attribution to these two provenance descriptions.
Description: The World Wide Web Consortium publishes technical reports according to its publication policy. Working drafts are published regularly to reflect the work accomplished by working groups. Every publication of a working draft must be preceded by a "publication request" to the Webmaster. The very first version of a technical report must also preceded by a "transition request" to be approved by the W3C director. All working drafts are made available at a unique URI. In this scenario, we consider two successive versions of a given report, the policy according to which they were published, and the associated requests.
Concretely, in this section, we describe the kind of provenance record that the WWW Consortium could keep for auditors to check that due processes are followed. All entities involved in this example are Web resources, with well defined URIs (some of which locating archived email messages, available to W3C Members).
We now paraphrase some PROV-DM descriptions, and illustrate them with the PROV-N notation, a notation for PROV-DM aimed at human consumption. We then follow them with a graphical illustration. Full details of the provenance record can be found here.
entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ])
wasGeneratedBy(tr:WD-prov-dm-20111215, ex:act2, -)
wasDerivedFrom(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018)
used(ex:act2, ar3:0111, -)
wasAssociatedWith(ex:act2, w3:Consortium, pr:rec-advance)
Provenance descriptions can be illustrated graphically. The illustration is not intended to represent all the details of the model, but it is intended to show the essence of a set of provenance descriptions. Therefore, it should not be seen as an alternate notation for expressing provenance.
The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and pentagonal shapes, respectively. Usage, Generation, Derivation, and Association are represented as directed edges.
Entities are laid out according to the ordering of their generation. We endeavor to show time progressing from left to right. This means that edges for Usage, Generation, Derivation, Association typically point leftwards
This simple example has shown a variety of PROV-DM constructs, such as Entity, Agent, Activity, Usage, Generation, Derivation, and Association. In this example, it happens that all entities were already Web resources, with readily available URIs, which we used. We note that some of the resources are public, whereas others have restricted access: provenance statements only make use of their identifiers. If identifiers do not pre-exist, e.g. for activities, then they can be generated, for instance ex:act2, occurring in the namespace identified by prefix ex. We note that the URI scheme developed by W3C is particularly suited for expressing provenance of these reports, since each URI denotes a specific version of a report. It then becomes very easy to relate the various versions, with PROV-DM constructs. We note that an Association is a ternary relation (represented by a multi-edge labeled wasAssociatedWith) from an activity to an agent and a plan.
Description: A technical report is edited by some editor, using contributions from various contributors.
Here, we consider another perspective on technical report http://www.w3.org/TR/2011/WD-prov-dm-20111215. Provenance is concerned with the document editing activity, as perceived by authors. This kind of information could be used by authors in their CV or in a narrative about this document.
Again, we paraphrase some PROV-DM descriptions, and illustrate them with the PROV-N notation. Full details of the provenance record can be found here.
entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])
While this description is about the same report tr:WD-prov-dm-20111215, its details differ from the author's perspective: it is a document and it has a version number.
wasGeneratedBy(tr:WD-prov-dm-20111215, ex:edit1, -)
agent(ex:Paolo, [ prov:type="Person" ]) agent(ex:Simon, [ prov:type="Person" ])
wasAssociatedWith(ex:edit1, ex:Paolo, -, [prov:role="editor"]) wasAssociatedWith(ex:edit1, ex:Simon, -, [prov:role="contributor"])
The two previous sections provide two different perspectives on the provenance of a technical report. By design, the PROV approach allows for the provenance of a subject to be provided by multiple sources. For users to decide whether they can place their trust in the technical report, they may want to analyze its provenance, but also determine who the provenance is attributed to, and when it was generated, etc. In other words, we need to be able to express the provenance of provenance.
No new mechanism is required to support this requirement. PROV-DM makes the assumption that provenance statements have been bundled up, and named, by some mechanism outside the scope of PROV-DM. For instance, in this case, provenance statements were put in a file and exposed on the Web, respectively at ex:w3c-publication1.pn and ex:w3c-publication3.pn. To express their respective provenance, these resources must be seen as entities, and all the constructs of PROV-DM are now available to characterize their provenance. In the example below, ex:w3c-publication1.pn is attributed to the agent w3:Consortium, whereas ex:w3c-publication3.pn to ex:Simon.
entity(ex:w3c-publication1.pn, [prov:type="prov:Account" %% xsd:QName ]) wasAttributedTo(ex:w3c-publication1.pn, w3:Consortium) entity(ex:w3c-publication3.pn, [prov:type="prov:Account" %% xsd:QName ]) wasAttributedTo(ex:w3c-publication3.pn, ex:Simon)
PROV-DM concepts are structured according to six components that are introduced in this section. Components and their dependencies are illustrated in Figure prov-dm-components. A component that relies on concepts defined in another also sits above it in this figure. PROV-DM consists of the following components.
While not all PROV-DM relations are binary, they all involve two primary elements. Hence, Table relations-at-a-glance indexes all relations according to their two primary elements. The table adopts the same color scheme as Figure prov-dm-components, allowing components to be readily identified. Note that for simplicity, this table does not include collection-oriented relations.
Entity | Activity | Agent | Note | |
Entity | wasGeneratedBy | wasAttributedTo | hasAnnotation | |
Activity | wasStartedByActivity wasInformedBy | wasAssociatedWith | hasAnnotation | |
Agent | — | — | actedOnBehalfOf | hasAnnotation |
Note | — | — | — | hasAnnotation |
Table prov-dm-concepts-and-relations is a complete index of all the concepts and relations in prov-dm, color-coded according to the component they belong too. In the first column, one finds concept names directly linking to their English definition. In the second column, we find their representation in the PROV-N notation, directly linking to the definition of their various constituents.
In the rest of the section, each concept and relation is defined, in English initially, followed by a more formal definition and some example.
The first component of PROV-DM is concerned with entities and activities, and their inter-relations: Usage, Generation, Start, End, Communication, and Start by Activity. Figure figure-component1 overviews the first component, with two "UML classes" and binary associations between them. Associations are not just binary; indeed, Usage, Generation, Start, End are remarkable because they have time attributes, which are placeholders for time information related to provenance.
The following expression
entity(tr:WD-prov-dm-20111215, [ prov:type="document", ex:version="2" ])states the existence of an entity, denoted by identifier tr:WD-prov-dm-20111215, with type document and version number 2. The attributes ex:version is application specific, whereas the attribute type is reserved in the PROV-DM namespace.
The following expression
activity(a1,2011-11-16T16:05:00,2011-11-16T16:06:00, [ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
states the existence of an activity with identifier a1, start time 2011-11-16T16:05:00, and end time 2011-11-16T16:06:00, running on host server.example.org, and of type edit. The attribute host is application specific (declared in some namespace with prefix ex). The attribute type is a reserved attribute of PROV-DM, allowing for sub-typing to be expressed.
Further considerations:
While each of the components activity, time, and attributes is optional, at least one of them must be present.
The following expressions
wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1"]) wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p2"])
state the existence of two generations (with respective times 2001-10-26T21:32:52 and 2001-10-26T10:00:00), at which new entities, identified by e1 and e2, are created by an activity, identified by a1. The first one is available on port p1, whereas the other is available on port p2. The semantics of port are application specific.
In some cases, we may want to record the time at which an entity was generated without having to specify the activity that generated it. To support this requirement, the activity component in generation is optional. Hence, the following expression indicates the time at which an entity is generated, without naming the activity that did it.
A reference to a given entity may appear in multiple usages that share a given activity identifier.
The following usages
used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"]) used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
state that the activity identified by a1 used two entities identified by e1 and e2, at times 2011-11-16T16:00:00 and 2011-11-16T16:00:01, respectively; the first one was found as the value of parameter p1, whereas the second was found as value of parameter p2. The semantics of parameter is application specific.
The following example contains the description of an activity a1 (a discussion), which was started at a specific time, and was triggered by an email message e1.
entity(e1,[prov:type="email message"]) activity(a1,[prov:type="Discuss"]) wasStartedBy(a1,e1,2011-11-16T16:05:00)Furthermore, if the activity happens to consume the message content, then the message would also be regarded as an input to the activity, which we describe as follows:
In the following example, a race is started by a bang, and responsibility for this trigger is attributed to an agent ex:DarthVader.
activity(ex:foot_race) wasStartedBy(ex:foot_race,ex:bang,2012-03-09T08:05:08-05:00) entity(ex:bang) agent(ex:DarthVader) wasAttributedTo(ex:foot_race,ex:DarthVader)
The relations wasStartedBy and used are orthogonal, and thus need to be expressed independently, according to the situation being described.
An activity end, written wasEndedBy(id,a,e,t,attrs) in PROV-N, contains:
The following example is a description of an activity a1 (editing) that was ended following an approval document e1.
entity(e1,[prov:type="approval document"]) activity(a1,[prov:type="Editing"]) wasEndedBy(a1,e1)
A communication implies that activity a2 is dependent on another a1, by way of some unspecified entity that is generated by a1 and used by a2.
Consider two long running services, which we represent by activities s1 and s2.
activity(s1, [prov:type="service"]) activity(s2, [prov:type="service"]) wasInformedBy(s2,s1)The last line indicates that some entity was generated by s1 and used by s2.
Suppose activities a1 and a2 are computer processes that are executed on different hosts, and that a1 started a2. This can be expressed as in the following fragment:
activity(a1,t1,t2,[ex:host="server1.example.org",prov:type="workflow"]) activity(a2,t3,t4,[ex:host="server2.example.org",prov:type="subworkflow"]) wasStartedByActivity(a2,a1)
The second component of PROV-DM is concerned with agents and the notions of Attribution, Association, Responsibility, relating agents to entities, activities, and agents, respectively. Figure figure-component2 depicts the second component, with four "UML classes" (Entity, Activity, Agent, and Plan) and associations between them. So-called "UML association classes" are used to express n-ary relations.
It is useful to define some basic categories of agents from an interoperability perspective. There are three types of agents that are common across most anticipated domains of use:
It is acknowledged that these types do not cover all kinds of agent.
The following expression is about an agent identified by e1, which is a person, named Alice, with employee number 1234.
agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])
It is optional to specify the type of an agent. When present, it is expressed using the prov:type attribute.
When an entity e is attributed to agent ag, entity e was generated by some unspecified activity that in turn was associated to agent ag. Thus, this relation is useful when the activity is not known, or irrelevant.
An attribution relation, written wasAttributedTo(id,e,ag,attrs) in PROV-N, contains the following elements:
Revisiting the example of Section 3.2, we can ascribe tr:WD-prov-dm-20111215 to some agents without an explicit activity.
agent(ex:Paolo, [ prov:type="Person" ]) agent(ex:Simon, [ prov:type="Person" ]) entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ]) wasAttributedTo(tr:WD-prov-dm-20111215, ex:Paolo, [prov:role="editor"]) wasAttributedTo(tr:WD-prov-dm-20111215, ex:Simon, [prov:role="contributor"])
In the following example, a designer and an operator agents are associated with an activity. The designer's goals are achieved by a workflow ex:wf.
activity(ex:a, [prov:type="workflow execution"]) agent(ex:ag1, [prov:type="operator"]) agent(ex:ag2, [prov:type="designer"]) wasAssociatedWith(ex:a, ex:ag1, -, [prov:role="loggedInUser", ex:how="webapp"]) wasAssociatedWith(ex:a, ex:ag2, ex:wf,[prov:role="designer", ex:context="project1"]) entity(ex:wf, [prov:type="prov:Plan" %% xsd:QName, ex:label="Workflow 1", ex:url="http://example.org/workflow1.bpel" %% xsd:anyURI])Since the workflow ex:wf is itself an entity, its provenance can also be expressed in PROV-DM: it can be generated by some activity and derived from other entities, for instance.
In some cases, one wants to indicate a plan was followed, without having to specify which agent was involved.
activity(ex:a,[prov:type="workflow execution"]) wasAssociatedWith(ex:a,-,ex:wf) entity(ex:wf,[prov:type="prov:Plan"%% xsd:QName, ex:label="Workflow 1", ex:url="http://example.org/workflow1.bpel" %% xsd:anyURI])In this case, it is assumed that an agent exists, but it has not been specified.
PROV-DM offers a mild version of responsibility in the form of a relation to represent when an agent acted on another agent's behalf. So in the example of someone running a mail program, the program and the person are both agents of the activity; furthermore, the mail software agent is running on the person's behalf. In another example, the student acted on behalf of his supervisor, who acted on behalf of the department chair, who acts on behalf of the university; all those agents are responsible in some way for the activity to take place but we do not say explicitly who bears responsibility and to what degree.
In the following example, a programmer, a researcher and a funder agents are described. The programmer and researcher are associated with a workflow activity. The programmer acts on behalf of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher. The terms 'delegation' and 'contact' used in this example are domain specific.
activity(a,[prov:type="workflow"]) agent(ag1,[prov:type="programmer"]) agent(ag2,[prov:type="researcher"]) agent(ag3,[prov:type="funder"]) wasAssociatedWith(a,ag1,[prov:role="loggedInUser"]) wasAssociatedWith(a,ag2) actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"]) actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
The third component of PROV-DM is concerned with derivations between entities, and subtypes of derivations Revision, Quotation, Original Source, and Traceability. Figure figure-component3 overviews the third component, with three "UML classes" (Entity, Activity, and Agent) and associations between them. So-called "UML association classes" are used to express n-ary relations.
According to Section Starting Points, for an entity to be transformed from, created from, or resulting from an update to another, there must be some underpinning activities performing the necessary actions resulting in such a derivation. A derivation can be described at various levels of precision. In its simplest form, derivation relates two entities. Optionally, attributes can be added to describe modalities of derivation. If the derivation is the result of a single known activity, then this activity can also be optionally expressed. And to provide a completely accurate description of the derivation, the generation and usage of the generated and used entities, respectively, can be provided. The reason for optional information such as activity, generation, and usage to be linked to derivations is to aid analysis of provenance and to facilitate provenance-based reproducibility.
The following descriptions state the existence of derivations.
wasDerivedFrom(e2, e1) wasDerivedFrom(e2, e1, [prov:type="physical transform"]) wasDerivedFrom(e2, e1, a, g2, u1) wasGeneratedBy(g2, e2, a, -) used(u1, a, e1, -)
The first and second lines are about derivations between e2 and e1, but no information is provided as to the identity of the activity (and usage and generation) underpinning the derivation. In the second line, a type attribute is also provided.
The third description expresses that activity a, using the entity e1 according to usage u1, derived the entity e2 and generated it according to generation g2. It is followed by descriptions for generation g2 and usage u1. With such a comprehensive description of derivation, a program that analyzes provenance can identify the activity underpinning the derivation, it can identify how the original entity e1 was used by the activity (e.g. for instance, which argument it was passed as, if the activity is the result of a function invocation), and which output the derived entity e2 was obtained from (say, for a function returning multiple results).
A revision is a derivation that revises an entity into a revised version.
Deciding whether something is made available as a revision of something else usually involves an agent who takes responsibility for approving that the former is a due variant of the latter. The agent who is responsible for the revision may optionally be specified. Revision is a particular case of derivation of an entity into its revised version.
A revision relation, written wasRevisionOf(id,e2,e1,ag,attrs) in PROV-N, contains:
Revisiting the example of Section 3.1, we can now state that the report tr:WD-prov-dm-20111215 is a revision of the report tr:WD-prov-dm-20111018, approved by agent w3:Consortium.
entity(tr:WD-prov-dm-20111215, [ prov:type="pr:RecsWD" %% xsd:QName ]) entity(tr:WD-prov-dm-20111018, [ prov:type="pr:RecsWD" %% xsd:QName ]) wasRevisionOf(tr:WD-prov-dm-20111215, tr:WD-prov-dm-20111018, w3:Consortium)
A quotation is the repeat of (some or all of) an entity, such as text or image, by someone other than its original author.
Quotation is a particular case of derivation in which entity e2 is derived from an original entity e1 by copying, or "quoting", some or all of it. A quotation relation, written wasQuotedFrom(id,e2,e1,ag2,ag1,attrs) in PROV-N, contains:
The following paragraph is a quote from one of the author's blogs.
"During the workshop, it became clear to me that the consensus based models (which are often graphical in nature) can not only be formalized but also be directly connected to these database focused formalizations. I just needed to get over the differences in syntax. This could imply that we could have nice way to trace provenance across systems and through databases and be able to understand the mathematical properties of this interconnection."
If wp:thoughts-from-the-dagstuhl-principles-of-provenance-workshop/ denotes the original blog by agent ex:Paul, and dm:bl-dagstuhl denotes the above paragraph, then the following descriptions express that the above paragraph is copied by agent ex:Luc from a part of the blog, attributed to the agent ex:Paul.
entity(wp:thoughts-from-the-dagstuhl-principles-of-provenance-workshop/) agent(ex:Luc) agent(ex:Paul) wasQuotedFrom(dm:bl-dagstuhl,wp:thoughts-from-the-dagstuhl-principles-of-provenance-workshop/,ex:Luc,ex:Paul)
An original source refers to the source material that is closest to the person, information, period, or idea being studied.
An original source relation is a particular case of derivation that aims to give credit to the source that originated some information. It is recognized that it may be hard to determine which entity constitutes an original source. This definition is inspired by original-source as defined in http://googlenewsblog.blogspot.com/2010/11/credit-where-credit-is-due.html.
An original source relation, written hadOriginalSource(id,e2,e1,attrs), contains:
Let us consider the current section dm:term-original-source, and the Google page go:credit-where-credit-is-due.html, where the notion was originally described.
entity(dm:term-original-source) entity(go:credit-where-credit-is-due.html) hadOriginalSource(dm:term-original-source,go:credit-where-credit-is-due.html)
Traceability is the ability to link back an entity to another by means of derivation or responsibility relations, possibly repeatedly traversed.
A traceability relation between two entities e2 and e1 is a generic dependency of e2 on e1 that indicates either that e1 may have been necessary for e2 to be created, or that e1 bears some responsibility for e2's existence.
Traceability, written tracedTo(id,e2,e1,attrs) in PROV-N, contains:
We note that the ancestor is allowed to be an agent since agents are entities.
Derivation and association are particular cases of traceability.
We refer to the example of Section 3.1, and specifically to Figure prov-tech-report. We can see that there is a path from tr:WD-prov-dm-20111215 to w3:Consortium or to pr:rec-advance. This is expressed as follows.
tracedTo(tr:WD-prov-dm-20111215,w3:Consortium) tracedTo(tr:WD-prov-dm-20111215,pr:rec-advance)
The fourth component of PROV-DM is concerned with relations specialization and alternate between entities. Figure figure-component4 overviews the component, which consists of a single "UML Class" and two associations.
Wherever two people describe the provenance of a same thing, one cannot expect them to coordinate and agree on the identifiers to use to denote that thing.
User Alice writes an article. In its provenance, she wishes to refer to the precise version of the article with a date-specific URI, as she might edit the article later. Alternatively, user Bob refers to the article in general, indepedently of its variants over time.
To allow for identifiers to be chosen freely and independently by each user, the PROV data model introduces relations that allow entities to be linked together. The following two relations are introduced for expressing specialized or alternate entities.
Examples of constraints include a time period, an abstraction, and a context associated with the entity.
The BBC news home page on 2012-03-23 ex:bbcNews2012-03-23 is a specialization of the BBC news page in general bbc:news/. This can be expressed as follows.
specializationOf(ex:bbcNews2012-03-23, bbc:news/)Given that the BBC news does not define a URI for this day's news page, we are creating a qualified name in the namespace ex.
A given news item on the BBC News site bbc:news/science-environment-17526723 for desktop is an alternate of a bbc:news/mobile/science-environment-17526723 for mobile devices.
entity(bbc:news/science-environment-17526723, [ prov:type="a news item for desktop"]) entity(bbc:news/mobile/science-environment-17526723, [ prov:type="a news item for mobile devices"]) alternateOf(bbc:news/science-environment-17526723, bbc:news/mobile/science-environment-17526723)
They are both specialization of an (unspecified) entity.
Considering again the two versions of the technical report tr:WD-prov-dm-20111215 (second working draft) and tr:WD-prov-dm-20111018 (first working draft). They are alternate of each other.
entity(tr:WD-prov-dm-20111018) entity(tr:WD-prov-dm-20111215) alternateOf(tr:WD-prov-dm-20111018,tr:WD-prov-dm-20111215)
They are both specialization of the page http://www.w3.org/TR/prov-dm/.
The fifth component of PROV-DM is concerned with the notion of collections. A collection is an entity that has some members. The members are themselves entities, and therefore their provenance can be expressed. In many applications, it is also of interest to be able to express the provenance of the collection itself: e.g. who maintains the collection, which member it contains at which point in time, and how it was assembled. The purpose of Component 5 is to define the types and relations that are useful to express the provenance of collections.
Figure figure-component5 overviews the component, which consists of two "UML Class" and three associations.
The intent of these relations and types is to express the history of changes that occurred to a collection. Changes to collections are about the insertion of entities to collections and the removal of members from collections. Indirectly, such history provides a way to reconstruct the contents of a collection.
Conceptually, a collection has a logical structure consisting of key-entity pairs. This structure is often referred to as a map, and is a generic indexing mechanisms that can abstract commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more (the specification of such specialized structures in terms of key-value pairs is out of the scope of this document).
A given collection forms a given structure for its members. A different structure (obtained either by insertion or removal of members) constitutes a different collection. Hence, for the purpose of provenance, a collection entity is viewed as a snapshot of a structure. Insertion and removal operations result in new snapshots, each snapshot forming an identifiable collection entity.
PROV-DM defines the following types related to collections:
entity(c0, [prov:type="EmptyCollection" %% xsd:QName]) // c0 is an empty collection entity(c1, [prov:type="Collection" %% xsd:QName]) // c1 is a collection, with unknown content
A Derivation-by-Insertion relation, written derivedByInsertionFrom(id, c2, c1, {(key_1, e_1), ..., (key_n, e_n)}, attrs), contains:
A Derivation-by-Insertion relation derivedByInsertionFrom(id, c2, c1, {(key_1, e_1), ..., (key_n, e_n)}) states that c2 is the state of the collection following the insertion of pairs (key_1, e_1), ..., (key_n, e_n) into collection c1.
entity(c0, [prov:type="EmptyCollection" %% xsd:QName]) // c0 is an empty collection entity(e1) entity(e2) entity(e3) entity(c1, [prov:type="Collection" %% xsd:QName]) entity(c2, [prov:type="Collection" %% xsd:QName]) derivedByInsertionFrom(c1, c0, {("k1", e1), ("k2", e2)}) derivedByInsertionFrom(c2, c1, {("k3", e3)})From this set of descriptions, we conclude:
c0 = { } c1 = { ("k1", e1), ("k2", e2) } c2 = { ("k1", e1), ("k2", e2), ("k3", e3) }
Insertion provides an "update semantics" for the keys that are already present in the collection, as illustrated by the following example.
entity(c0, [prov:type="EmptyCollection" %% xsd:QName]) // c0 is an empty collection entity(e1) entity(e2) entity(e3) entity(c1, [prov:type="Collection" %% xsd:QName]) entity(c2, [prov:type="Collection" %% xsd:QName]) derivedByInsertionFrom(c1, c0, {("k1", e1), ("k2", e2)}) derivedByInsertionFrom(c2, c1, {("k1", e3)})This is a case of update of e1 to e3 for the same key, "k1".
c0 = { } c1 = { ("k1", e1), ("k2", e2) } c2 = { ("k1", e3), ("k2", e2) }
A Derivation-by-Removal relation, written derivedByRemovalFrom(id, c2, c1, {key_1, ... key_n}, attrs), contains:
Derivation-by-Removal relation derivedByRemovalFrom(id, c2,c1, {key_1, ..., key_n}) states that c2 is the state of the collection following the removal of the set of pairs corresponding to keys key_1...key_n from c1.
entity(c0, [prov:type="EmptyCollection"]) // c0 is an empty collection entity(e1) entity(e2) entity(e3) entity(c1, [prov:type="Collection"]) entity(c2, [prov:type="Collection"]) derivedByInsertionFrom(c1, c0, {("k1", e1), ("k2",e2)}) derivedByInsertionFrom(c2, c1, {("k3", e3)}) derivedByRemovalFrom(c3, c2, {"k1", "k3"})From this set of descriptions, we conclude:
c0 = { } c1 = { ("k1", e1), ("k2", e2) } c2 = { ("k1", e1), ("k2", e2), ("k3", e3) } c3 = { ("k2", e2) }
The insertion and removal relations make insertions and removals explicit as part of the history of a collection. This, however, requires explicit mention of the state of the collection prior to each operation. The membership relation removes this needs, allowing the state of a collection c to be expressed without having to introduce a prior state.
The description memberOf(c, {(key_1, e_1), ..., (key_n, e_n)}) states that c is known to include (key_1, e_1), ..., (key_n, e_n)}, without having to introduce a previous state.
entity(c, [prov:type="prov:Collection" %% xsd:QName]) // c is a collection, with unknown content activity(a) wasGeneratedBy(c,a) // a produced c entity(e1) entity(e2) memberOf(c, {("k1", e1), ("k2", e2)} ) entity(e3) entity(c1, [prov:type="prov:Collection" %% xsd:QName]) derivedByInsertionFrom(c1, c, {("k3", e3)})From this set of assertions, we conclude:
c contains ("k1", e1), ("k2", e2) c1 contains ("k1", e1), ("k2", e2), ("k3", v3)Note that the state of c1 with these relations is only partially known, because the state of c is unknown.
Further considerations:
The sixth component of PROV-DM is concerned with notes and annotations.
As provenance descriptions are exchanged between systems, it may be useful to add extra-information to what they are describing. For instance, a "trust service" may add value-judgements about the trustworthiness of some of the entities or agents involved. Likewise, an interactive visualization component may want to enrich a set of provenance descriptions with information helping reproduce their visual representation. To help with interoperability, PROV-DM introduces a simple annotation mechanism allowing anything that is identifiable to be associated with notes. For this, a type and and a relation are introduced.
The annotation mechanism (with note and annotation) forms a key aspect of the extensibility mechanism of PROV-DM (see extensibility section).
The following note consists of a set of application-specific attribute-value pairs, intended to help the rendering of what it is associated with, by specifying its color and its position on the screen.
note(ex2:n1,[ex2:color="blue", ex2:screenX=20, ex2:screenY=30]) hasAnnotation(tr:WD-prov-dm-20111215,ex2:n1)
The note is associated with the entity tr:WD-prov-dm-20111215. Relation hasAnnotation is discussed in the next section. The note's identifier and attributes are declared in a separate namespace denoted by prefix ex2.
Alternatively, a reputation service may enrich a provenance record with notes providing reputation ratings about agents. In the following fragment, both agents ex:Simon and ex:Paolo are rated "excellent".
note(ex3:n2,[ex3:reputation="excellent"]) hasAnnotation(ex:Simon,ex3:n2) hasAnnotation(ex:Paolo,ex3:n2)
The note's identifier and attributes are declared in a separate namespace denoted by prefix ex3.
Multiple notes can be associated with a given identified object; symmetrically, multiple objects can be associated with a given note. Since notes have identifiers, they can also be annotated.
The following expressions
entity(e1,[prov:type="document"]) entity(e2,[prov:type="document"]) activity(a,t1,t2) used(u1,a,e1,[ex:file="stdin"]) wasGeneratedBy(e2, a, [ex:file="stdout"]) note(n1,[ex:icon="doc.png"]) hasAnnotation(e1,n1) hasAnnotation(e2,n1) note(n2,[ex:style="dotted"]) hasAnnotation(u1,n2)
describe two documents (attribute-value pair: prov:type="document") identified by e1 and e2, and their annotation with a note indicating that the icon (an application specific way of rendering provenance) is doc.png. The example also includes an activity, its usage of the first entity, and its generation of the second entity. The usage is annotated with a style (an application specific way of rendering this edge graphically). To be able to express this annotation, the usage was provided with an identifier u1, which was then referred to in hasAnnotation(u1,n2).
A PROV-DM namespace is identified by an IRI [IRI]. In PROV-DM, attributes, identifiers, and values with qualified names as data type can be placed in a namespace using the mechanisms described in this specification.
A namespace declaration consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this declaration refers to this namespace. A default namespace declaration consists of a namespace. Every un-prefixed qualified name in the scope of this default namespace declaration refers to this namespace.
The PROV-DM namespace is http://www.w3.org/ns/prov#.
PROV-DM stipulates that a qualified name can be mapped into an IRI by concatenating the IRI associated with the prefix and the local part.
A qualified name's prefix is optional. If a prefix occurs in a qualified name, it refers to a namespace declared in a namespace declaration. In the absence of prefix, the qualified name refers to the default namespace.
An identifier is a qualified name.
An attribute is a qualified name.
The PROV data model introduces a pre-defined set of attributes in the PROV-DM namespace, which we define below. The interpretation of any attribute declared in another namespace is out of scope.
The attribute prov:label provides a human-readable representation of a PROV-DM element or relation. The value associated with the attribute prov:label must be a string.
The following entity is provided with a label attribute.
entity(ex:e1, [prov:label="This is a label"])
A location can be an identifiable geographic place (ISO 19112), but it can also be a non-geographic place such as a directory, row, or column. As such, there are numerous ways in which location can be expressed, such as by a coordinate, address, landmark, and so forth. This document does not specify how to concretely express locations, but instead provide a mechanism to introduce locations, by means of a reserved attribute.
The attribute prov:location is an optional attribute of entity and activity. The value associated with the attribute prov:location must be a PROV-DM Value, expected to denote a location.
The following expression describes entity Mona Lisa, a painting, with a location attribute.
entity(ex:MonaLisa, [prov:location="Le Louvres, Paris", prov:type="StillImage"])
The attribute prov:role denotes the function of an entity with respect to an activity, in the context of a usage, generation, association, start, and end. The attribute prov:role is allowed to occur multiple times in a list of attribute-value pairs. The value associated with a prov:role attribute must be a PROV-DM Value.
The following activity start describes the role of the agent identified by ag in this start relation with activity a.
wasStartedBy(a,ag, [prov:role="program-operator"])
The attribute prov:type provides further typing information for an element or relation. PROV-DM liberally defines a type as a category of things having common characteristics. PROV-DM is agnostic about the representation of types, and only states that the value associated with a prov:type attribute must be a PROV-DM Value. The attribute prov:type is allowed to occur multiple times.
The following describes an agent of type software agent.
agent(ag, [prov:type="prov:SoftwareAgent" %% xsd:QName])
The following types are pre-defined in PROV, and are valid values for the prov:type attribute.
By means of attribute-value pairs, the PROV data model can refer to values such as strings, numbers, time, qualified names, and IRIs. The interpretation of such values is outside the scope of PROV-DM.
Each kind of such values is called a datatype. The datatypes are taken from the set of XML Schema Datatypes, version 1.1 [XMLSCHEMA-2] and the RDF specification [RDF-CONCEPTS]. The normative definitions of these datatypes are provided by the respective specifications. Each datatype is identified by its XML xsd:QName.
We note that PROV-DM time instants are defined according to xsd:dateTime [XMLSCHEMA-2].
The following examples respectively are the string "abc", the string "abc", the integer number 1, and the IRI "http://example.org/foo".
"abc" 1 "http://example.org/foo" %% xsd:anyURI
The following example shows a value of type xsd:QName (see QName [XMLSCHEMA-2]). The prefix ex must be bound to a namespace declared in a namespace declaration.
"ex:value" %% xsd:QName
In the following example, the generation time of entity e1 is expressed according to xsd:dateTime [XMLSCHEMA-2].
wasGeneratedBy(e1,a1, 2001-10-26T21:32:52)
The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
The PROV-DM namespace declares a set of reserved attributes catering for extensibility: type, role, location.
The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged. To ensure interoperability, specializations of the PROV data model that exploit the extensibility points summarized in this section must preserve the semantics specified in the PROV-DM documents (part 1 to 3).
The example of section 3 contains identifiers such as tr:WD-prov-dm-20111215, which denotes a specific version of a technical report. On the other hand, a URI such as http://www.w3.org/TR/prov-dm/ points to the latest version of a document. One needs to ensure that provenance descriptions for the latter document remain valid as denoted resources change.
To this end, PROV-DM allows asserters to describe "partial states" of entities by means of attributes and associated values. Some further constraints apply to the use of these attributes, since the values associated with them are expected to remain unchanged for some period of time. The constraints associated to attributes allow provenance descriptions to be refined, they can also be found in the companion specification [PROV-DM-CONSTRAINTS].
Even though a mechanism for blundling up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named bundle is being referred to as an account and is regarded as an Account so that its provenance can be expressed. The notion of account is specified in the companion specification [PROV-DM-CONSTRAINTS], as well as constraint that structurally well-formed descriptions are expected to satisfy.
WG membership to be listed here.


text:
CREATE TYPE(7) | PostgreSQL 16.3 Documentation | CREATE TYPE(7) |
CREATE_TYPE - define a new data type
CREATE TYPE name AS ( [ attribute_name data_type [ COLLATE collation ] [, ... ] ] ) CREATE TYPE name AS ENUM ( [ 'label' [, ... ] ] ) CREATE TYPE name AS RANGE ( SUBTYPE = subtype [ , SUBTYPE_OPCLASS = subtype_operator_class ] [ , COLLATION = collation ] [ , CANONICAL = canonical_function ] [ , SUBTYPE_DIFF = subtype_diff_function ] [ , MULTIRANGE_TYPE_NAME = multirange_type_name ] ) CREATE TYPE name ( INPUT = input_function, OUTPUT = output_function [ , RECEIVE = receive_function ] [ , SEND = send_function ] [ , TYPMOD_IN = type_modifier_input_function ] [ , TYPMOD_OUT = type_modifier_output_function ] [ , ANALYZE = analyze_function ] [ , SUBSCRIPT = subscript_function ] [ , INTERNALLENGTH = { internallength | VARIABLE } ] [ , PASSEDBYVALUE ] [ , ALIGNMENT = alignment ] [ , STORAGE = storage ] [ , LIKE = like_type ] [ , CATEGORY = category ] [ , PREFERRED = preferred ] [ , DEFAULT = default ] [ , ELEMENT = element ] [ , DELIMITER = delimiter ] [ , COLLATABLE = collatable ] ) CREATE TYPE name
CREATE TYPE registers a new data type for use in the current database. The user who defines a type becomes its owner.
If a schema name is given then the type is created in the specified schema. Otherwise it is created in the current schema. The type name must be distinct from the name of any existing type or domain in the same schema. (Because tables have associated data types, the type name must also be distinct from the name of any existing table in the same schema.)
There are five forms of CREATE TYPE, as shown in the syntax synopsis above. They respectively create a composite type, an enum type, a range type, a base type, or a shell type. The first four of these are discussed in turn below. A shell type is simply a placeholder for a type to be defined later; it is created by issuing CREATE TYPE with no parameters except for the type name. Shell types are needed as forward references when creating range types and base types, as discussed in those sections.
Composite Types
The first form of CREATE TYPE creates a composite type. The composite type is specified by a list of attribute names and data types. An attribute's collation can be specified too, if its data type is collatable. A composite type is essentially the same as the row type of a table, but using CREATE TYPE avoids the need to create an actual table when all that is wanted is to define a type. A stand-alone composite type is useful, for example, as the argument or return type of a function.
To be able to create a composite type, you must have USAGE privilege on all attribute types.
Enumerated Types
The second form of CREATE TYPE creates an enumerated (enum) type, as described in Section 8.7. Enum types take a list of quoted labels, each of which must be less than NAMEDATALEN bytes long (64 bytes in a standard PostgreSQL build). (It is possible to create an enumerated type with zero labels, but such a type cannot be used to hold values before at least one label is added using ALTER TYPE.)
Range Types
The third form of CREATE TYPE creates a new range type, as described in Section 8.17.
The range type's subtype can be any type with an associated b-tree operator class (to determine the ordering of values for the range type). Normally the subtype's default b-tree operator class is used to determine ordering; to use a non-default operator class, specify its name with subtype_opclass. If the subtype is collatable, and you want to use a non-default collation in the range's ordering, specify the desired collation with the collation option.
The optional canonical function must take one argument of the range type being defined, and return a value of the same type. This is used to convert range values to a canonical form, when applicable. See Section 8.17.8 for more information. Creating a canonical function is a bit tricky, since it must be defined before the range type can be declared. To do this, you must first create a shell type, which is a placeholder type that has no properties except a name and an owner. This is done by issuing the command CREATE TYPE name, with no additional parameters. Then the function can be declared using the shell type as argument and result, and finally the range type can be declared using the same name. This automatically replaces the shell type entry with a valid range type.
The optional subtype_diff function must take two values of the subtype type as argument, and return a double precision value representing the difference between the two given values. While this is optional, providing it allows much greater efficiency of GiST indexes on columns of the range type. See Section 8.17.8 for more information.
The optional multirange_type_name parameter specifies the name of the corresponding multirange type. If not specified, this name is chosen automatically as follows. If the range type name contains the substring range, then the multirange type name is formed by replacement of the range substring with multirange in the range type name. Otherwise, the multirange type name is formed by appending a _multirange suffix to the range type name.
Base Types
The fourth form of CREATE TYPE creates a new base type (scalar type). To create a new base type, you must be a superuser. (This restriction is made because an erroneous type definition could confuse or even crash the server.)
The parameters can appear in any order, not only that illustrated above, and most are optional. You must register two or more functions (using CREATE FUNCTION) before defining the type. The support functions input_function and output_function are required, while the functions receive_function, send_function, type_modifier_input_function, type_modifier_output_function, analyze_function, and subscript_function are optional. Generally these functions have to be coded in C or another low-level language.
The input_function converts the type's external textual representation to the internal representation used by the operators and functions defined for the type. output_function performs the reverse transformation. The input function can be declared as taking one argument of type cstring, or as taking three arguments of types cstring, oid, integer. The first argument is the input text as a C string, the second argument is the type's own OID (except for array types, which instead receive their element type's OID), and the third is the typmod of the destination column, if known (-1 will be passed if not). The input function must return a value of the data type itself. Usually, an input function should be declared STRICT; if it is not, it will be called with a NULL first parameter when reading a NULL input value. The function must still return NULL in this case, unless it raises an error. (This case is mainly meant to support domain input functions, which might need to reject NULL inputs.) The output function must be declared as taking one argument of the new data type. The output function must return type cstring. Output functions are not invoked for NULL values.
The optional receive_function converts the type's external binary representation to the internal representation. If this function is not supplied, the type cannot participate in binary input. The binary representation should be chosen to be cheap to convert to internal form, while being reasonably portable. (For example, the standard integer data types use network byte order as the external binary representation, while the internal representation is in the machine's native byte order.) The receive function should perform adequate checking to ensure that the value is valid. The receive function can be declared as taking one argument of type internal, or as taking three arguments of types internal, oid, integer. The first argument is a pointer to a StringInfo buffer holding the received byte string; the optional arguments are the same as for the text input function. The receive function must return a value of the data type itself. Usually, a receive function should be declared STRICT; if it is not, it will be called with a NULL first parameter when reading a NULL input value. The function must still return NULL in this case, unless it raises an error. (This case is mainly meant to support domain receive functions, which might need to reject NULL inputs.) Similarly, the optional send_function converts from the internal representation to the external binary representation. If this function is not supplied, the type cannot participate in binary output. The send function must be declared as taking one argument of the new data type. The send function must return type bytea. Send functions are not invoked for NULL values.
You should at this point be wondering how the input and output functions can be declared to have results or arguments of the new type, when they have to be created before the new type can be created. The answer is that the type should first be defined as a shell type, which is a placeholder type that has no properties except a name and an owner. This is done by issuing the command CREATE TYPE name, with no additional parameters. Then the C I/O functions can be defined referencing the shell type. Finally, CREATE TYPE with a full definition replaces the shell entry with a complete, valid type definition, after which the new type can be used normally.
The optional type_modifier_input_function and type_modifier_output_function are needed if the type supports modifiers, that is optional constraints attached to a type declaration, such as char(5) or numeric(30,2). PostgreSQL allows user-defined types to take one or more simple constants or identifiers as modifiers. However, this information must be capable of being packed into a single non-negative integer value for storage in the system catalogs. The type_modifier_input_function is passed the declared modifier(s) in the form of a cstring array. It must check the values for validity (throwing an error if they are wrong), and if they are correct, return a single non-negative integer value that will be stored as the column "typmod". Type modifiers will be rejected if the type does not have a type_modifier_input_function. The type_modifier_output_function converts the internal integer typmod value back to the correct form for user display. It must return a cstring value that is the exact string to append to the type name; for example numeric's function might return (30,2). It is allowed to omit the type_modifier_output_function, in which case the default display format is just the stored typmod integer value enclosed in parentheses.
The optional analyze_function performs type-specific statistics collection for columns of the data type. By default, ANALYZE will attempt to gather statistics using the type's "equals" and "less-than" operators, if there is a default b-tree operator class for the type. For non-scalar types this behavior is likely to be unsuitable, so it can be overridden by specifying a custom analysis function. The analysis function must be declared to take a single argument of type internal, and return a boolean result. The detailed API for analysis functions appears in src/include/commands/vacuum.h.
The optional subscript_function allows the data type to be subscripted in SQL commands. Specifying this function does not cause the type to be considered a "true" array type; for example, it will not be a candidate for the result type of ARRAY[] constructs. But if subscripting a value of the type is a natural notation for extracting data from it, then a subscript_function can be written to define what that means. The subscript function must be declared to take a single argument of type internal, and return an internal result, which is a pointer to a struct of methods (functions) that implement subscripting. The detailed API for subscript functions appears in src/include/nodes/subscripting.h. It may also be useful to read the array implementation in src/backend/utils/adt/arraysubs.c, or the simpler code in contrib/hstore/hstore_subs.c. Additional information appears in Array Types below.
While the details of the new type's internal representation are only known to the I/O functions and other functions you create to work with the type, there are several properties of the internal representation that must be declared to PostgreSQL. Foremost of these is internallength. Base data types can be fixed-length, in which case internallength is a positive integer, or variable-length, indicated by setting internallength to VARIABLE. (Internally, this is represented by setting typlen to -1.) The internal representation of all variable-length types must start with a 4-byte integer giving the total length of this value of the type. (Note that the length field is often encoded, as described in Section 73.2; it's unwise to access it directly.)
The optional flag PASSEDBYVALUE indicates that values of this data type are passed by value, rather than by reference. Types passed by value must be fixed-length, and their internal representation cannot be larger than the size of the Datum type (4 bytes on some machines, 8 bytes on others).
The alignment parameter specifies the storage alignment required for the data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte boundaries. Note that variable-length types must have an alignment of at least 4, since they necessarily contain an int4 as their first component.
The storage parameter allows selection of storage strategies for variable-length data types. (Only plain is allowed for fixed-length types.) plain specifies that data of the type will always be stored in-line and not compressed. extended specifies that the system will first try to compress a long data value, and will move the value out of the main table row if it's still too long. external allows the value to be moved out of the main table, but the system will not try to compress it. main allows compression, but discourages moving the value out of the main table. (Data items with this storage strategy might still be moved out of the main table if there is no other way to make a row fit, but they will be kept in the main table preferentially over extended and external items.)
All storage values other than plain imply that the functions of the data type can handle values that have been toasted, as described in Section 73.2 and Section 38.13.1. The specific other value given merely determines the default TOAST storage strategy for columns of a toastable data type; users can pick other strategies for individual columns using ALTER TABLE SET STORAGE.
The like_type parameter provides an alternative method for specifying the basic representation properties of a data type: copy them from some existing type. The values of internallength, passedbyvalue, alignment, and storage are copied from the named type. (It is possible, though usually undesirable, to override some of these values by specifying them along with the LIKE clause.) Specifying representation this way is especially useful when the low-level implementation of the new type "piggybacks" on an existing type in some fashion.
The category and preferred parameters can be used to help control which implicit cast will be applied in ambiguous situations. Each data type belongs to a category named by a single ASCII character, and each type is either "preferred" or not within its category. The parser will prefer casting to preferred types (but only from other types within the same category) when this rule is helpful in resolving overloaded functions or operators. For more details see Chapter 10. For types that have no implicit casts to or from any other types, it is sufficient to leave these settings at the defaults. However, for a group of related types that have implicit casts, it is often helpful to mark them all as belonging to a category and select one or two of the "most general" types as being preferred within the category. The category parameter is especially useful when adding a user-defined type to an existing built-in category, such as the numeric or string types. However, it is also possible to create new entirely-user-defined type categories. Select any ASCII character other than an upper-case letter to name such a category.
A default value can be specified, in case a user wants columns of the data type to default to something other than the null value. Specify the default with the DEFAULT key word. (Such a default can be overridden by an explicit DEFAULT clause attached to a particular column.)
To indicate that a type is a fixed-length array type, specify the type of the array elements using the ELEMENT key word. For example, to define an array of 4-byte integers (int4), specify ELEMENT = int4. For more details, see Array Types below.
To indicate the delimiter to be used between values in the external representation of arrays of this type, delimiter can be set to a specific character. The default delimiter is the comma (,). Note that the delimiter is associated with the array element type, not the array type itself.
If the optional Boolean parameter collatable is true, column definitions and expressions of the type may carry collation information through use of the COLLATE clause. It is up to the implementations of the functions operating on the type to actually make use of the collation information; this does not happen automatically merely by marking the type collatable.
Array Types
Whenever a user-defined type is created, PostgreSQL automatically creates an associated array type, whose name consists of the element type's name prepended with an underscore, and truncated if necessary to keep it less than NAMEDATALEN bytes long. (If the name so generated collides with an existing type name, the process is repeated until a non-colliding name is found.) This implicitly-created array type is variable length and uses the built-in input and output functions array_in and array_out. Furthermore, this type is what the system uses for constructs such as ARRAY[] over the user-defined type. The array type tracks any changes in its element type's owner or schema, and is dropped if the element type is.
You might reasonably ask why there is an ELEMENT option, if the system makes the correct array type automatically. The main case where it's useful to use ELEMENT is when you are making a fixed-length type that happens to be internally an array of a number of identical things, and you want to allow these things to be accessed directly by subscripting, in addition to whatever operations you plan to provide for the type as a whole. For example, type point is represented as just two floating-point numbers, which can be accessed using point[0] and point[1]. Note that this facility only works for fixed-length types whose internal form is exactly a sequence of identical fixed-length fields. For historical reasons (i.e., this is clearly wrong but it's far too late to change it), subscripting of fixed-length array types starts from zero, rather than from one as for variable-length arrays.
Specifying the SUBSCRIPT option allows a data type to be subscripted, even though the system does not otherwise regard it as an array type. The behavior just described for fixed-length arrays is actually implemented by the SUBSCRIPT handler function raw_array_subscript_handler, which is used automatically if you specify ELEMENT for a fixed-length type without also writing SUBSCRIPT.
When specifying a custom SUBSCRIPT function, it is not necessary to specify ELEMENT unless the SUBSCRIPT handler function needs to consult typelem to find out what to return. Be aware that specifying ELEMENT causes the system to assume that the new type contains, or is somehow physically dependent on, the element type; thus for example changing properties of the element type won't be allowed if there are any columns of the dependent type.
Because there are no restrictions on use of a data type once it's been created, creating a base type or range type is tantamount to granting public execute permission on the functions mentioned in the type definition. This is usually not an issue for the sorts of functions that are useful in a type definition. But you might want to think twice before designing a type in a way that would require "secret" information to be used while converting it to or from external form.
Before PostgreSQL version 8.3, the name of a generated array type was always exactly the element type's name with one underscore character (_) prepended. (Type names were therefore restricted in length to one fewer character than other names.) While this is still usually the case, the array type name may vary from this in case of maximum-length names or collisions with user type names that begin with underscore. Writing code that depends on this convention is therefore deprecated. Instead, use pg_type.typarray to locate the array type associated with a given type.
It may be advisable to avoid using type and table names that begin with underscore. While the server will change generated array type names to avoid collisions with user-given names, there is still risk of confusion, particularly with old client software that may assume that type names beginning with underscores always represent arrays.
Before PostgreSQL version 8.2, the shell-type creation syntax CREATE TYPE name did not exist. The way to create a new base type was to create its input function first. In this approach, PostgreSQL will first see the name of the new data type as the return type of the input function. The shell type is implicitly created in this situation, and then it can be referenced in the definitions of the remaining I/O functions. This approach still works, but is deprecated and might be disallowed in some future release. Also, to avoid accidentally cluttering the catalogs with shell types as a result of simple typos in function definitions, a shell type will only be made this way when the input function is written in C.
In PostgreSQL version 16 and later, it is desirable for base types' input functions to return "soft" errors using the new errsave()/ereturn() mechanism, rather than throwing ereport() exceptions as in previous versions. See src/backend/utils/fmgr/README for more information.
This example creates a composite type and uses it in a function definition:
CREATE TYPE compfoo AS (f1 int, f2 text); CREATE FUNCTION getfoo() RETURNS SETOF compfoo AS $$ SELECT fooid, fooname FROM foo $$ LANGUAGE SQL;
This example creates an enumerated type and uses it in a table definition:
CREATE TYPE bug_status AS ENUM ('new', 'open', 'closed'); CREATE TABLE bug ( id serial, description text, status bug_status );
This example creates a range type:
CREATE TYPE float8_range AS RANGE (subtype = float8, subtype_diff = float8mi);
This example creates the base data type box and then uses the type in a table definition:
CREATE TYPE box; CREATE FUNCTION my_box_in_function(cstring) RETURNS box AS ... ; CREATE FUNCTION my_box_out_function(box) RETURNS cstring AS ... ; CREATE TYPE box ( INTERNALLENGTH = 16, INPUT = my_box_in_function, OUTPUT = my_box_out_function ); CREATE TABLE myboxes ( id integer, description box );
If the internal structure of box were an array of four float4 elements, we might instead use:
CREATE TYPE box ( INTERNALLENGTH = 16, INPUT = my_box_in_function, OUTPUT = my_box_out_function, ELEMENT = float4 );
which would allow a box value's component numbers to be accessed by subscripting. Otherwise the type behaves the same as before.
This example creates a large object type and uses it in a table definition:
CREATE TYPE bigobj ( INPUT = lo_filein, OUTPUT = lo_fileout, INTERNALLENGTH = VARIABLE ); CREATE TABLE big_objs ( id integer, obj bigobj );
More examples, including suitable input and output functions, are in Section 38.13.
The first form of the CREATE TYPE command, which creates a composite type, conforms to the SQL standard. The other forms are PostgreSQL extensions. The CREATE TYPE statement in the SQL standard also defines other forms that are not implemented in PostgreSQL.
The ability to create a composite type with zero attributes is a PostgreSQL-specific deviation from the standard (analogous to the same case in CREATE TABLE).
2024 | PostgreSQL 16.3 |

subset: commoncrawl


text:
Family and friends will recollect how special their loved one was with this gentle ring of pastel blooms. Highlighted with a pink satin ribbon, it is a lovely reminder of sweet memories and beautiful times shared.
Peach roses, gerberas and carnations, pink asiatic lilies and lisianthus, along with purple limonium and lavender larkspur - accented by greens woven throughout - are presented on an easel-mounted wreath, ideal for a memorial occasion.


text:
Cost-per-click (CPC) bidding means that you pay for each click on your ads. For CPC bidding campaigns, you set a maximum cost-per-click bid - or simply "max. CPC" - that's the highest amount that you're willing to pay for a click on your ad (unless you're setting bid adjustments, or using Enhanced CPC).
- Your max. CPC is the most you'll typically be charged for a click, but you'll often be charged less - sometimes much less. That final amount you're charged for a click is called your actual CPC.
- If you enter a max. CPC bid and someone clicks your ad, that click won't cost you more than the maximum CPC bid amount that you set.
- You'll choose between manual bidding (you choose your bid amounts) and automatic bidding (let Google set bids to try to get the most clicks within your budget).
- CPC pricing is sometimes known as pay-per-click (PPC).


text:
Join Us
Infinity MileageLands
Earn Miles, Fly More
From now on, Join Infinity MileageLands and earn miles within your journey or life, such as Award Miles and Status Miles of flight miles, Award Miles of credit cards, accommodation, and car rental. Furthermore, there're variety of benefits to grant you a spectacular flying experience and comfortable journey.
Join Infinity MileageLands online and get 500 miles for free, fill in your data to earn another 500 miles. Join us!
Earning Mileage
Infinity MileageLands gives you fast and easy ways to earn miles with EVA Air /UNI Air international flights, Star Alliance member carrier's flights, credit card companies, participating hotels, car rentals, and etc.....
Tiers and Privileges
The more you fly, the more benefits you have! Taking EVA/ UNI Air international flights and Star Alliances flights allows you to upgrade your card tier, enjoy benefits such as Tier Bonus Award Miles, usage of Lounges, exclusive checking counter, extra baggage allowance.
Miles & Cash
Now you can use miles as cash when buying tickets via the EVA Air website! It lets you use mileage much more flexible.
Mileage Redemption
Let's earn more miles to redeem award tickets, upgrade awards, or hotel vouchers.


text:
The Order of the Knights of Saint Mulumba Nigeria (KSM) has elected Diamond Ovueraye, as the Supreme Knight and head of the new supreme executive board to govern its affairs for the next four years.
The group in a statement yesterday said the new supreme board comprising of twelve-member executives will be led by Ovueraye who emerged unopposed. Prior to his emergence, Ovueraye was the Deputy Supreme Knight and had acted as the Supreme Knight in the last three months.
The election which was the main agenda of a special KSM Supreme Convention was held at the Madonna Retreat Centre, Nkpor near Onitsha and had in attendance all the accredited and statutory delegates from the two hundred and fifty Sub-Councils in the nine metropolitan councils of the Order.
According to the constitution of KSM, it was supervised by the Supreme Chaplain of KSM Rev. Fr. Dr. Francis Nwaiwu, who was assisted by KSM Chaplains from Benin and Onitsha Sub Councils.
In his acceptance speech, the Supreme Knight commended the amity that pervaded the conduct of the election and enjoined all the elected officers to dedicate themselves to the ennobling cannons of the Order and pledged to provide purposeful leadership at all times.
On his agenda, the former senior manager who had worked with Shell and travelled to different continents said his tenure will vigorously pursue and ensure increased spirituality, positive impact and growth of membership and sub-councils. Others are "Advocacy, deepening relationship with the CBCN, streamlining and fine tuning of administrative channels, rekindling of true brotherhood, internal charity, and maintaining discipline."
According to him,: "As knights, we must all strive to be change agents in our families, offices, businesses, communities and the Church. This way our light will dispel the pervading darkness and then we can really be said to be good soldiers of Christ.
Earlier in his exhortation, the Supreme Chaplain Rev. Fr. Dr. Nwaiwu had urged the delegates to ensure that the best interest of the Order is paramount by electing a very competent Supreme Executive Board to pilot its affairs. He further admonished the delegates to eschew base consideration in their choice of candidates and implored those elected to be exemplary.
Other officers elected were Bro. Charles Mbelede, Deputy Supreme Knight, Bro. Fabian Obi, Supreme Secretary, Bro. Henry Bello, Supreme Advocate, Bro. Francis Ogini, Supreme Chancellor and Bro. Greg Esotu, Supreme Treasurer. Also elected were Bro. Patrick Ekwenta as Supreme Financial Secretary, Bro. Emmanuel Ikpam as Supreme Auditor, Bro. Charles Eregie as Supreme Physician, Bro. Emma Onyejekwe as Supreme Warden, Bro. Dan Egwu as Supreme PRO/Editor and Bro. Moses Iyasere as Supreme Assistant Secretary.
One of the newly elected officers, Bro Dan Egwu, said, "Knights must live a sacrificial life of service and endeavour to be exemplary, bearing in mind that the measure we give is the measure that will be given to us."


text:
Monday 18 November 2013
Mozillians At The Tongariro Crossing And Orakei Korako
Last weekend some local and visiting Mozillians (visiting for a Gecko media work week), plus assorted loved ones (such as my children), drove down to Tongariro National Park to do the Tongariro Crossing on Saturday.
The weather was reasonably good --- cloudy, but mostly dry. As often, there was thick fog up on the mountain, clearing as we descended the northern flank. Even though the fog eliminates some of the amazing views, it's still very atmospheric and fun in its own way. It does help conceal the other thousand people doing the hike :-).
I've done the TC several times before but this was the first time I've done it since last year's eruption from Tongariro's Te Maari crater. That has made the TC even more interesting! On the descent past Te Maari you can now see large quantities of steam venting from the crater --- quite impressive. The Ketetahi Hut was hit by boulders from the eruption, and overnight stays are now forbidden there for safety reasons. Two decent-sized holes punched in the hut roof have been preserved and make an excellent argument for following the rules :-). An even better argument is just down the track from the hut: a sizable impact crater, with the impacting boulder mostly buried at the bottom of it. No-one was at the hut on the night of the eruption, but if they had been, it would have been a terrifying experience!
Near the end of the track, it crosses a stream. Lahar activity associated with the Te Maari eruption has blocked the original course of the stream, so the existing bridges are over dry streambeds. Now the stream spreads through the bush in other places and we had to splash across.
We finished the walk in just over seven hours, and a good time was had by all.
On Sunday some of us drove back to Auckland via Orakei Korako. I hadn't been there since I was a child, even though I really enjoy geothermal areas. I very much enjoyed Orakei Korako! It has an excellent mix of features --- geysers, silica terraces, hot pools, boiling mud, and a cave --- all in a lovely bush setting, plus you cross a small lake in a boat to get to it. This is my second favourite geothermal area in New Zealand, after Waimangu Valley. Waimangu's Frying Pan Lake is hard to top :-).


text:
Despite the 6.5% stock market rally over the last three months, a handful of billionaires are quietly dumping their American stocks . . . and fast.
Warren Buffett, who has been a cheerleader for U.S. stocks for quite some time, is dumping shares at an alarming rate. He recently complained of "disappointing performance" in dyed-in-the-wool American companies like Johnson & Johnson, Procter & Gamble, and Kraft Foods.
In the latest filing for Buffett's holding company Berkshire Hathaway, Buffett has been drastically reducing his exposure to stocks that depend on consumer purchasing habits. Berkshire sold roughly 19 million shares of Johnson & Johnson, and reduced his overall stake in "consumer product stocks" by 21%. Berkshire Hathaway also sold its entire stake in California-based computer parts supplier Intel.
With 70% of the U.S. economy dependent on consumer spending, Buffett's apparent lack of faith in these companies' future prospects is worrisome.
Unfortunately Buffett isn't alone.
Fellow billionaire John Paulson, who made a fortune betting on the subprime mortgage meltdown, is clearing out of U.S. stocks too. During the second quarter of the year, Paulson's hedge fund, Paulson & Co., dumped 14 million shares of JPMorgan Chase. The fund also dumped its entire position in discount retailer Family Dollar and consumer-goods maker Sara Lee.
Finally, billionaire George Soros recently sold nearly all of his bank stocks, including shares of JPMorgan Chase, Citigroup, and Goldman Sachs. Between the three banks, Soros sold more than a million shares.
So why are these billionaires dumping their shares of U.S. companies?
After all, the stock market is still in the midst of its historic rally. Real estate prices have finally leveled off, and for the first time in five years are actually rising in many locations. And the unemployment rate seems to have stabilized.
It's very likely that these professional investors are aware of specific research that points toward a massive market correction, as much as 90%.
One such person publishing this research is Robert Wiedemer, an esteemed economist and author of the New York Times best-selling book Aftershock.
Editor's Note: Wiedemer Gives Proof for His Dire Predictions in This Shocking Interview.
Before you dismiss the possibility of a 90% drop in the stock market as unrealistic, consider Wiedemer's credentials.
In 2006, Wiedemer and a team of economists accurately predicted the collapse of the U.S. housing market, equity markets, and consumer spending that almost sank the United States. They published their research in the book America's Bubble Economy.
The book quickly grabbed headlines for its accuracy in predicting what many thought would never happen, and quickly established Wiedemer as a trusted voice.
A columnist at Dow Jones said the book was "one of those rare finds that not only predicted the subprime credit meltdown well in advance, it offered Main Street investors a winning strategy that helped avoid the forty percent losses that followed . . ."
The chief investment strategist at Standard & Poor's said that Wiedemer's track record "demands our attention."
And finally, the former CFO of Goldman Sachs said Wiedemer's "prescience in (his) first book lends credence to the new warnings. This book deserves our attention."
In the interview for his latest blockbuster Aftershock, Wiedemer says the 90% drop in the stock market is "a worst-case scenario," and the host quickly challenged this claim.
Wiedemer calmly laid out a clear explanation of why a large drop of some sort is a virtual certainty.
It starts with the reckless strategy of the Federal Reserve to print a massive amount of money out of thin air in an attempt to stimulate the economy.
"These funds haven't made it into the markets and the economy yet. But it is a mathematical certainty that once the dam breaks, and this money passes through the reserves and hits the markets, inflation will surge," said Wiedemer.
"Once you hit 10% inflation, 10-year Treasury bonds lose about half their value. And by 20%, any value is all but gone. Interest rates will increase dramatically at this point, and that will cause real estate values to collapse. And the stock market will collapse as a consequence of these other problems."
See the Proof: Get the Full Interview by Clicking Here Now.
And this is where Wiedemer explains why Buffett, Paulson, and Soros could be dumping U.S. stocks:
"Companies will be spending more money on borrowing costs than business expansion costs. That means lower profit margins, lower dividends, and less hiring. Plus, more layoffs."
No investors, let alone billionaires, will want to own stocks with falling profit margins and shrinking dividends. So if that's why Buffett, Paulson, and Soros are dumping stocks, they have decided to cash out early and leave Main Street investors holding the bag.
But Main Street investors don't have to see their investment and retirement accounts decimated for the second time in five years.
Wiedemer's video interview also contains a comprehensive blueprint for economic survival that's really commanding global attention.
Now viewed over 40 million times, it was initially screened for a relatively small, private audience. But the overwhelming amount of feedback from viewers who felt the interview should be widely publicized came with consequences, as various online networks repeatedly shut it down and affiliates refused to house the content.
"People were sitting up and taking notice, and they begged us to make the interview public so they could easily share it," said Newsmax Financial Publisher Aaron DeHoog.
"Our real concern," DeHoog added, "is the effect even if only half of Wiedemer's predictions come true.
"That's a scary thought for sure. But we want the average American to be prepared, and that is why we will continue to push this video to as many outlets as we can. We want the word to spread."
Editor's Note: For a limited time, Newsmax is showing the Wiedemer interview and supplying viewers with copies of the new, updated Aftershock book including the final, unpublished chapter. Go here to view it now.
Moderators: Blogitter Team


text:
Development Tools
Debuginfo Package Improvements
To observe what a program is doing, Fedora provides additional meta-data about code that is installed and runs on your system. These can be used together with tracers, profilers and debuggers to better understand what is running on your system (or to understand crashes or failures better). Previously, these debug info meta-data packages were fairly large, containing lots of information about multiple sub-packages together. With Fedora 27, these debug info meta-data packages have been split up into smaller sub-packages, making it possible to install just the debuginfo for one specific sub-package or library. The source files needed for debuggers (but not necessarily for tracers and profilers) have been separated out into their own debugsource package and it is now possible to install multiple, different versions or architectures of the debug info packages at the same time. For example, when trying to introspect a program installed in a container or virtual machine that is a different version of the package installed on the host, or when both a 32 bit and 64 bit version of a library is available.
Bodhi Now Handles Non-RPM Artifacts
Bodhi, the Fedora Updates System, can now handle more than just RPM files. If it can be tagged in Koji, it should be accepted by Bodhi. The release of Bodhi 3.0.0 enables:
Support for updating non-RPM artifacts, like modules.
Support for complex package dependencies, which enables Fedora to start packaging Rust packages and allows Fedora to do a better job expressing valid ranges of supported dependency versions for existing packages.
Support, via Pungi, for generating OSTrees that are more consistent with Fedora's release day OSTrees.
More information about this update to Bodhi can be found in the Bodhi 3.0.0 release notes and the related Fedora change page.
Want to help? Learn how to contribute to Fedora Docs ›