The user-subjective approach is the first interaction design approach dedicated specifically to personal information management (PIM). The approach offers design principles with which PIM systems (e.g. operating systems, email applications and web browsers) can make systematic use of subjective (i.e. user-dependent) attributes. The approach evolved in three stages: (a) theoretical foundations first published in a Journal of the American Society for Information Science and Technology during 2003. The paper introduces the approach and its design principles (b) evidence and implementation was published in another JASIST paper in 2008. The paper gives empirical evidence in support of the approach as well as seven novel design schemes that derives from it. It has won the Best JASIST paper award in 2009.(c) specific design evaluation this stage has already begun with evaluation of the first user-subjective design prototype called GrayArea in a Conference on Human Factors in Computing Systems paper published in 2009. == Theoretical foundations == The user-subjective approach takes advantage of the fact that in PIM the person who retrieves the information is the same person who had previously stored it. PIM can be seen as a communication between the person and him\her self at two different times: the time of storage and the time of retrieval. The PIM system design should help facilitate that unique communication by allowing the user use subjective (user-dependent) attributes in addition to the standard objective ones. PIM systems should capture these subjective attributes when the user interacts with the information item (either automatically or by using direct manipulation interface) in order to help the user retrieve the item later on. The user-subjective approach identifies three subjective attributes – the project which the item was classified to, its degree of importance to the user, and the context in which the item was used during the interaction with it. The approach also assigns a design principle for each. The principles (discussed below) are deliberately abstract to allow for a variety of different implementations. === The subjective project classification principle === The subjective project classification principle suggests that PIM systems design should allow all information items related to a project be classified under the same category regardless of whether they are files, emails, Web Favorites or of any other format. This stands in sharp contrast with the present PIM system design where there are distinct folder hierarchies for each of these formats. The current design forces the user to store information related to a single project in separate locations depending on their format causing the project fragmentation problem. === The subjective importance principle === The subjective importance principle suggests that the subjective importance of information should affect its degree of visual salience and accessibility: important information items should be highly visible and accessible as they are more likely to be retrieved (the promotion principle) and those of lower importance should be demoted (i.e. making them less visible) so as not to distract the user (the demotion principle). While the promotion principle is not new and has been widely applied in PIM system design, the demotion principle is novel and has been applied only sporadically in these systems. Currently these systems allow only two options: keeping information (where unneeded information items could clutter folders and obscure the target item) and deleting it (where there is a risk that the item will not be there when needed). Demotion suggests a third option where the item is less visible so it doesn’t distract the user but is kept within its original context in case the user would need it after all. === The subjective context principle === The subjective context principle suggests that PIM systems should allow users retrieve their information items in the same context that they had previously used in order to bridge the time gap between these two events. By "context" the approach refers to other information items that were used at the time of interaction with the item, thoughts that the users may have regarding the item, the phase the user got to in the interaction with the item and other people the user collaborates with regarding the information item. == Evidence and implementations == === Evidence === The user-subjective approach was evaluated in a multioperational designed study which used questionnaires, screen shots and in-depth interviews (N = 84). The research tested the use of subjective attributes in current PIM systems and its dependency on design. Results show that participants used subjective attributes whenever design allowed them to. When it didn't, they either used their own alternative ways to use these attributes or avoided using subjective attributes at all. Regarding the subjective project classification principle – many of the participants' recent files, emails and web pages related to the same projects (indicating that they were working on the same project using different formats), and they had saved files of different format in the same project folders. However, as design does not suggest storing emails and web favorites with files, users avoid doing so. Regarding the subjective importance principle – users tended to retrieve their important information from highly visible and accessible locations offered by current design (e.g. by using the desktop), however since current systems offers no way to demote files of low subjective importance participants tended to use their own walk around ways for doing so (e.g. by moving them to a folder called "old" inside their original folder). Regarding the subjective context principle – participants tended to talk spontaneously about the context of their information items during the interview. These evidence imply that current PIM systems could possibly be improved if it would allow users to make more use of subjective attributes of their personal information. === Implementations === Each of the user-subjective design principles can be implemented in various ways. Moreover, as the approach is generative it offers PIM designers to use these principles in order to create their own user subjective designs. Below are design schemes that demonstrate an implementation of each of the principles. A more complete set of implementation examples can be found in the user-subjective website Archived 2011-02-01 at the Wayback Machine. The single hierarchy solution – addresses the project fragmentation problem (the current situation where the users stores and retrieve their project-related files, emails and web favorites at different hierarchies) and implements the subjective classification principle by offering the user a single folder hierarchy for all information items. At the operation system level the users would navigate to a folder and find there all project related files, emails, web favorites, tasks, contacts and notes. This would allow them to retrieve all their project-related information items from a single location regardless of their formats. When looking at these folders at their mail box the users would see only their emails and only web favorites through their browser. The single hierarchy design scheme has not been evaluated yet. GrayArea – implements the demotion principle by allowing users to move subjectively unimportant files to a gray area at the bottom end of their folders. This clears the upper part of the folder from file that are unlikely to be retrieved while allowing the users to retrieve these unimportant file in their original context in case they are needed after all. GrayArea design scheme was positively evaluated (see next section). ItemHistory – is an implementation of the subjective context principle. It allows users to reach all information items that were previously retrieved while that information item was open. This design scheme has not been evaluated to date. == Specific design evaluation == The evaluation of specific designs is the third and final step of the approach development. It had begun with the assessment of GrayArea. === GrayArea evaluation === GrayArea was evaluated by using a prototype that simulated the participants' folders but included a gray area where they could drag & drop their subjectively unimportant files. In the study 96 participants were asked to clean up their folders from unimportant files once with GrayArea and once without it. Results show that the use of GrayArea reduced the clutter in folders, that it was easier for participants to demote files than to delete them and that they would use it if provided in their next operating system. These results encourage commercial implementation of GrayArea and the development and testing of other user-subjective designs. == Chronological development == The user-subjective approach was developed by
Digital sculpting
Digital sculpting, also known as sculpt modeling or 3D sculpting, is the use of software that offers tools to push, pull, smooth, grab, pinch or otherwise manipulate a digital object as if it were made of a real-life substance such as clay. == Sculpting technology == The geometry used in digital sculpting programs to represent the model can vary; each offers different benefits and limitations. The majority of digital sculpting tools on the market use mesh-based geometry, in which an object is represented by an interconnected surface mesh of polygons that can be pushed and pulled around. This is somewhat similar to the physical process of beating copper plates to sculpt a scene in relief. Other digital sculpting tools use voxel-based geometry, in which the volume of the object is the basic element. Material can be added and removed, much like sculpting in clay. Still other tools make use of more than one basic geometry representation. A benefit of mesh-based programs is that they support sculpting at multiple resolutions on a single model. Areas of the model that are finely detailed can have very small polygons while other areas can have larger polygons. In many mesh-based programs, the mesh can be edited at different levels of detail, and the changes at one level will propagate to higher and lower levels of model detail. A limitation of mesh-based sculpting is the fixed topology of the mesh; the specific arrangement of the polygons can limit the ways in which detail can be added or manipulated. A benefit of voxel-based sculpting is that voxels allow complete freedom over form. The topology of a model can be altered continually during the sculpting process as material is added and subtracted, which frees the sculptor from considering the layout of polygons on the model's surface. After sculpting, it may be necessary to retopologize the model to obtain a clean mesh for use in animation or real-time rendering. Voxels, however, are more limited in handling multiple levels of detail. Unlike mesh-based modeling, broad changes made to voxels at a low level of detail may completely destroy finer details. == Uses == Sculpting can often introduce details to meshes that would otherwise have been difficult or impossible to create using traditional 3D modeling techniques. This makes it preferable for achieving photorealistic and hyperrealistic results, though, many stylized results are achieved as well. Sculpting is primarily used in high poly organic modeling (the creation of 3D models which consist mainly of curves or irregular surfaces, as opposed to hard surface modeling). It is also used by auto manufacturers in their design of new cars. It can create the source meshes for low poly game models used in video games. In conjunction with other 3D modeling and texturing techniques and Displacement and Normal mapping, it can greatly enhance the appearance of game meshes often to the point of photorealism. Some sculpting programs like 3D-Coat, Zbrush, and Mudbox offer ways to integrate their workflows with traditional 3D modeling and rendering programs. Conversely, 3D modeling applications like 3ds Max, Maya and MODO are now incorporating sculpting capability as well, though these are usually less advanced than tools found in sculpting-specific applications. High poly sculpts are also extensively used in CG artwork for movies, industrial design, art, photorealistic illustrations, and for prototyping in 3D printing. == 3D print == Sculptors and digital artists use digital sculpting to create a model (or Digital Twin) to be materialized through CNC technologies including 3D printing. The final sculptures are often called Digital Sculpture or 3D printed art. While digital technologies have emerged in many art disciplines (painting, photography), this is less the case for digital sculpture due to the higher complexity and technology limitations to produce the final sculpture. == Sculpting Process == The best way to learn sculpture is by understanding primary, secondary and tertiary forms. First, break down the object you want to make down its basic shapes, such as a sphere or cube. Focus on making the large, overall shape of the object. After that, work on the bigger shapes on top of or inside the object. These can be protrusions or cut outs. Then, do a final detail pass, such as pores or lines to break up the shape. == Sculpting programs == There are a number of digital sculpting tools available. Some popular tools for creating are: Traditional 3D modeling suites are also beginning to include sculpting capability. 3D modeling programs which currently feature some form of sculpting include the following:
Graphical Kernel System
The Graphical Kernel System (GKS) is a 2D computer graphics system using vector graphics, introduced in 1977. It was suitable for making line and bar charts and similar tasks. A key concept was cross-system portability, based on an underlying coordinate system that could be represented on almost any hardware. GKS is best known as the basis for the graphics in the GEM GUI system used on the Atari ST and as part of Ventura Publisher. A draft international standard was circulated for review in September 1983. Final ratification of the standard was achieved in 1985, making it the first ISO graphics standard. A 3D system modelled on GKS was introduced as PHIGS, which saw some use in the 1980s and early 1990s. == Overview == GKS provides a set of drawing features for two-dimensional vector graphics suitable for charting and similar duties. The calls are designed to be portable across different programming languages, graphics devices and hardware, so that applications written to use GKS will be readily portable to many platforms and devices. GKS was fairly common on computer workstations in the 1980s and early 1990s. GKS formed the basis of Digital Research's GSX which evolved into VDI, one of the core components of GEM. GEM was the native GUI on the Atari ST and was occasionally seen on PCs, particularly in conjunction with Ventura Publisher. GKS was little used commercially outside these markets, but remains in use in some scientific visualization packages. It is also the underlying API defining the Computer Graphics Metafile. One popular application based on an implementation of GKS is the GR Framework, a C library for high-performance scientific visualization that has become a common plotting backend among Julia users. A main developer and promoter of the GKS was José Luis Encarnação, formerly director of the Fraunhofer Institute for Computer Graphics (IGD) in Darmstadt, Germany. GKS has been standardized in the following documents: ANSI standard ANSI X3.124 of 1985. ISO 7942:1985 standard, revised as ISO 7942:1985/Amd 1:1991 and ISO/IEC 7942-1:1994, as well as ISO/IEC 7942-2:1997, ISO/IEC 7942-3:1999 and ISO/IEC 7942-4:1998 The language bindings are ISO standard ISO 8651. GKS-3D (Graphical Kernel System for Three Dimensions) functional definition is ISO standard ISO 8805, and the corresponding C bindings are ISO/IEC 8806. The functionality of GKS is wrapped up as a data model standard in the STEP standard, section ISO 10303-46.
Image-based modeling and rendering
In computer graphics and computer vision, image-based modeling and rendering (IBMR) methods rely on a set of two-dimensional images of a scene to generate a three-dimensional model and then render some novel views of this scene. The traditional approach of computer graphics has been used to create a geometric model in 3D and try to reproject it onto a two-dimensional image. Computer vision, conversely, is mostly focused on detecting, grouping, and extracting features (edges, faces, etc.) present in a given picture and then trying to interpret them as three-dimensional clues. Image-based modeling and rendering allows the use of multiple two-dimensional images in order to generate directly novel two-dimensional images, skipping the manual modeling stage. == Light modeling == Instead of considering only the physical model of a solid, IBMR methods usually focus more on light modeling. The fundamental concept behind IBMR is the plenoptic illumination function which is a parametrisation of the light field. The plenoptic function describes the light rays contained in a given volume. It can be represented with seven dimensions: a ray is defined by its position ( x , y , z ) {\displaystyle (x,y,z)} , its orientation ( θ , ϕ ) {\displaystyle (\theta ,\phi )} , its wavelength ( λ ) {\displaystyle (\lambda )} and its time ( t ) {\displaystyle (t)} : P ( x , y , z , θ , ϕ , λ , t ) {\displaystyle P(x,y,z,\theta ,\phi ,\lambda ,t)} . IBMR methods try to approximate the plenoptic function to render a novel set of two-dimensional images from another. Given the high dimensionality of this function, practical methods place constraints on the parameters in order to reduce this number (typically to 2 to 4). == IBMR methods and algorithms == View morphing generates a transition between images Panoramic imaging renders panoramas using image mosaics of individual still images Lumigraph relies on a dense sampling of a scene Space carving generates a 3D model based on a photo-consistency check
Voyages: The Trans-Atlantic Slave Trade Database
Voyages: The Trans-Atlantic Slave Trade Database is a database hosted at Rice University that aims to present all documentary material pertaining to the transatlantic slave trade. It is a sister project to African Origins. The database breaks down the kingdoms and countries that engaged in the Atlantic trade. By 2008, the project had gathered data on nearly 35,000 transatlantic slave voyages from 1501 to 1867. For each voyage they sought to establish dates, owners, vessels, captains, African visits, American destinations, numbers of slaves embarked, and numbers landed. They have been able to find much of this material for an estimated 80 percent of the entire transatlantic African slave trade. With corrections for missing voyages, the Project has estimated the entire size of the transatlantic slave trade with more comprehension, precision, and accuracy than before. They reckon that in 366 years, slaving vessels embarked about 12.5 million captives in Africa, and landed 10.7 million in the New World. A horrific discovery is a careful estimate that the Middle Passage took a toll of more than 1.8 million African lives. In this quantitative database, the numbers are enslaved people.
EPUAP
ePUAP (Electronic Platform of Public Administration Services) is a Polish nationwide platform for communication of citizens with public administrations in a uniform and standardized way. Built as part of the ePUAP-WKP project (State Informatization Plan). Service providers are public administration units and public institutions (especially entities that perform tasks commissioned by the state). The platform provides service providers with technological infrastructure to provide services to citizens (recipients). Among the participants of ePUAP there are both central administration units and local governments, including municipal offices. Among the services offered by ePUAP is also Profil Zaufany (Trusted Profile), which enables electronic filing with legal effect without the need to use a qualified signature and SAML-based single sign-on mechanism, which enables the same ePUAP account to log on to websites of various service providers. The website www.epuap.gov.pl enables defining citizen and businesses service processes, creates channels of access to different systems of public administration and extends the package of public services provided electronically. Services available through the ePUAP platform may be accessed at the official website. Currently all administration services are available in Polish only. == Overview == It is described by the Polish government as "a coherent and systematic action program designed and developed to allow public institutions make their electronic services available to the public". The platform provides citizens, businesses and institutions with a number of services intended to ensure smooth and safe communication between: customer to administrations (C2A), business to administration (B2A), administration to administration (A2A). === Main goals === The main project objectives are to create a single, secure and electronic access channel to public services for citizens, businesses and public administration and also to reduce time and lower the costs of sharing information resources and functionalities of administration domain systems. Within the project, the following functionalities and services were delivered: Public services catalogue – a method of presenting and describing administration services, ePUAP platform – a web platform designed to provide public services on the Internet, Interoperability portal – a portal for experts working on recommendations for electronic documents and forms used within Polish administration systems to assure the uniformity of IT standards, Central Repository of Electronic Document Models – a database for valid document models and electronic forms. == History and background == The ePUAP project was carried out in the years 2005–2008. Currently, a continuation project ePUAP2 is being carried out with the following objectives: to increase the number of online services available to the public including the registry services, to widen the scale of usage of public electronic services, to integrate subsequent systems of public administration and business on ePUAP portal, to define new processes of customer and business services. === ePUAP2 === ePUAP2 is a public and administrative project that extends the set of functional services developed during the first edition of the project and is another step in the process of transforming Poland into a modern and citizen-friendly country. The implementation period for the project covers the years 2009–2013. Project financing The cost of the project “Construction of electronic Platform of Public Administration Services” – 32 million PLN was covered in 75% by the funds from the European Regional Development Fund (under the Sector Operational Programme "Supporting Competitiveness of Enterprises for the years 2004–2006"), while the remaining 25% of the cost was covered by a Polish national co-financing. Funds for the ePUAP2 project were gained from the 7th priority axis of the Innovative Economy Operational Programme and amounts to 140 million PLN (85% of eligible expenses were covered by the European Regional Development Fund, 15% were covered by a national co-financing). The trustee of ePUAP is the Polish Ministry of the Interior and Administration. == Legal regulations == According to the Polish law from 1 May 2008, public authorities are required to accept documents in electronic form (bringing applications and proposals and other activities in electronic form). ePUAP enables public institutions to meet this requirement by providing a service infrastructure to set up am electronic inbox. The ePUAP inbox meets legal requirements, in particular: issuing an official confirmation of receipt in accordance with the regulation of the Prime Minister of 29 September 2005 on the organizational and technical conditions for the delivery of electronic documents to public entities; cooperation with hardware security modules (HSM), meeting the technical requirements set out in the law; handling documents electronically in accordance with the minimum requirements set out in the Regulation of the Polish Council of Ministers of 11 October 2005 on minimum requirements for ICT systems. == Incidents == === Crashes === The ePUAP system very often happens smaller or larger failures. Because it is used to sign the application profiles trusted also in other electronic systems such as public administration. Electronic Services Platform created by ZUS, the system fault ePUAP it very difficult to settle official matters most electronically. === "Infoafera" === According to TVN and the release of TVP News from 10 April 2014, the creation of ePUAP is also associated with the so-called "Infoafera." On 10 April 2014, the Minister of Internal Affairs of Poland confirmed the information that the American technology company HP confessed to its participation in the Polish info-tour and corruption of Polish officials. By March 2014, the construction of ePUAP and its maintenance cost PLN 98.4 million. PLN 67.8 million has been used for this project. Challenged expenses only on the portal itself is approx. PLN 20 million.
Security type system
In computer science, a type system can be described as a syntactic framework which contains a set of rules that are used to assign a type property (int, boolean, char etc.) to various components of a computer program, such as variables or functions. A security type system works in a similar way, only with a main focus on the security of the computer program, through information flow control. Thus, the various components of the program are assigned security types, or labels. The aim of a such system is to ultimately be able to verify that a given program conforms to the type system rules and satisfies non-interference. Security type systems is one of many security techniques used in the field of language-based security, and is tightly connected to information flow and information flow policies. In simple terms, a security type system can be used to detect if there exists any kind of violation of confidentiality or integrity in a program, i.e. the programmer wants to detect if the program is in line with the information flow policy or not. == A simple information flow policy == Suppose there are two users, A and B. In a program, the following security classes (SC) are introduced: SC = {∅, {A}, {B}, {A,B}}, where ∅ is the empty set. The information flow policy should define the direction that information is allowed to flow, which is dependent on whether the policy allows read or write operations. This example considers read operations (confidentiality). The following flows are allowed: → = {({A}, {A}), ({B}, {B}), ({A,B}, {A,B}), ({A,B}, {A}), ({A,B}, {B}), ({A}, ∅), ({B}, ∅), ({A,B}, ∅)} This can also be described as a superset (⊇). In words: information is allowed to flow towards stricter levels of confidentiality. The combination operator (⊕) can express how security classes can perform read operations with respect to other security classes. For example: {A} ⊕ {A,B} = {A} — the only security class that can read from both {A} and {A,B} is {A}. {A} ⊕ {B} = ∅ — neither {A} nor {B} are allowed to read from both {A} and {B}. This can also be described as an intersection (∩) between security classes. An information flow policy can be illustrated as a Hasse diagram. The policy should also be a lattice, that is, it has a greatest lower-bound and least upper-bound (there always exists a combination between security classes). In the case of integrity, information will flow in the opposite direction, thus the policy will be inverted. == Information flow policy in security type systems == Once the policy is in place, the software developer can apply the security classes to the program components. Use of a security type system is usually combined with a compiler that can perform the verification of the information flow according to the type system rules. For the sake of simplicity, a very simple computer program, together with the information flow policy as described in the previous section, can be used as a demonstration. The simple program is given in the following pseudocode: if y{A} = 1 then x{A,B} := 0 else x{A,B} := 1 Here, an equality check is made on a variable y that is assigned the security class {A}. A variable x with a lower security class ({A,B}) is influenced by this check. This means that information is leaking from class {A} to class {A,B}, which is a violation of the confidentiality policy. This leak should be detected by the security type system. === Example === Designing a security type system requires a function (also known as a security environment) that creates a mapping from variables to security types, or classes. This function can be called Γ, such that Γ(x) = τ, where x is a variable and τ is the security class, or type. Security classes are assigned (also called "judgement") to program components, using the following notation: Types are assigned to read operations by: Γ ⊢ e : τ. Types are assigned to write operations by: Γ ⊢ S : τ cmd. Constants can be assigned any type. The following bottom-up notation can be used to decompose the program: assumption1 ... assumptionn/conclusion. Once the program is decomposed into trivial judgements, by which the type can easily be determined, the types for the less trivial parts of the program can be derived. Each "numerator" is considered in isolation, looking at the type of each statement to see if an allowed type can be derived for the "denominator", based on the defined type system "rules". ==== Rules ==== The main part of the security type system is the rules. They say how the program should be decomposed and how type verification should be performed. This toy program consists of a conditional test and two possible variable assignments. Rules for these two events are defined as follows: Applying this to the simple program introduced above yields: The type system detects the policy violation in line 2, where a read operation of security class {A} is performed, followed by two write operations of a less strict security class {A,B}. In more formalized terms, {A} ⋢ {A,B}, {A,B} (from the rule of the conditional test). Thus, the program is classified as "not typeable". === Soundness === The soundness of a security type system can be informally defined as: If program P is well typed, P satisfies non-interference. Volpano, Smith and Irvine were the first to prove soundness of a security type system for a deterministic imperative programming language with a standard (non-instrumented) semantics using the notion of non-interference.