U.S. patent application number 16/686543 was filed with the patent office on 2020-03-12 for user interface apparatus and methods.
This patent application is currently assigned to METATOMIX, INC.. The applicant listed for this patent is METATOMIX, INC.. Invention is credited to Patrick Curley, Mark Ingerman.
Application Number | 20200081690 16/686543 |
Document ID | / |
Family ID | 42099794 |
Filed Date | 2020-03-12 |
View All Diagrams
United States Patent
Application |
20200081690 |
Kind Code |
A1 |
Ingerman; Mark ; et
al. |
March 12, 2020 |
User Interface Apparatus and Methods
Abstract
In one aspect, the invention provides a digital data processing
system for information storage and retrieval that includes a first
digital data processor (e.g., personal computer, workstation,
server, mainframe, etc.) coupled to a second digital data processor
and a data store (e.g., a RDF data store, relational database,
etc.). The first digital data processor creates, reads, updates
and/or deletes data from the data store (i.e., "CRUD" operations)
based on a model generated by the first digital data processor. The
model comprises an ontology and a set of constraints that are
applied to data characterized by the ontology.
Inventors: |
Ingerman; Mark; (Newton,
MA) ; Curley; Patrick; (Winchester, MA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
METATOMIX, INC. |
Dedham |
MA |
US |
|
|
Assignee: |
METATOMIX, INC.
Dedham
MA
|
Family ID: |
42099794 |
Appl. No.: |
16/686543 |
Filed: |
November 18, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12576027 |
Oct 8, 2009 |
10481878 |
|
|
16686543 |
|
|
|
|
61104211 |
Oct 9, 2008 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 16/78 20190101;
G06F 8/35 20130101 |
International
Class: |
G06F 8/35 20060101
G06F008/35 |
Claims
1. A digital data processing system, comprising: A. a first digital
data processor coupled to (i) a second digital data processor and
(ii) a data store, B. a model comprising an ontology and a set of
constraints, C. the first digital data processor any of creating,
reading, updating and deleting data from the data store based on
code generated from the model by said first digital data
processor.
2.-57. (canceled)
Description
[0001] This application claims the benefit of priority of U.S.
Patent Application Ser. No. 61/104,211 filed Oct. 9, 2008, having
the same title hereof, the teachings of which are incorporated
herein by reference.
BACKGROUND OF THE INVENTION
[0002] The invention pertains to digital data processing and, more
particularly, to methods and apparatus for facilitating digital
data information storage and retrieval operations, e.g., data
create, read, update, and delete operations.
[0003] In today's marketplace, many advanced data management
systems focus on providing back-end support for data storage and
retrieval. They are generally geared towards developers, who use
Application Programming Interfaces (APIs) supplied with the
packages to write "one-off" applications (e.g., with Java Swing)
that permit users to create, access, delete and otherwise
"interface" with the data. While this facilitates (and, indeed,
necessitates) customization, a drawback is increased time and
expense at inception and throughout the lifetime of each custom
application. This has led to slow adoption of many advanced data
management technologies by business enterprises and the like.
[0004] One advanced data management technology that is coming to
the fore is semantic data management. These are technologies that
utilize knowledge space-specific vocabularies to improve data
retrieval, if not also data storage. In addition to the hurdles
discussed above, however, current semantic data packages typically
do not provide security features desired by many enterprises (e.g.,
financial institutions). The packages focus, instead, on improving
data retrieval and, as a consequence, necessitate increased
attention to security by application developers.
[0005] An object of the invention is to provide improved methods
and apparatus for digital data processing.
[0006] A further object of the invention is to provide such methods
and apparatus as facilitate digital data information storage and
retrieval. A related object of the invention is to provide such
methods and apparatus as facilitate data creation, retrieval,
update and deletion ("CRUD") operations.
[0007] A further related object is to provide such methods and
apparatus as facilitate the development and life-time maintenance
of data management applications.
[0008] A still further object of the invention is to provide such
methods and apparatus as ensure data security.
[0009] A yet still further object of the invention is to provide
such methods and apparatus as are adapted for use with semantic
data systems, as well as other advanced data technologies.
SUMMARY OF THE INVENTION
[0010] The foregoing objects are among those attained by the
invention which provides, in one aspect, a digital data processing
system for information storage and retrieval that includes a first
digital data processor (e.g., personal computer, workstation,
server, mainframe, etc.) coupled to a second digital data processor
and a data store (e.g., a RDF data store, relational database,
etc.). The first digital data processor creates, reads, updates
and/or deletes data from the data store (i.e., "CRUD" operations)
based on a model generated by the first digital data processor. The
model comprises an ontology and a set of constraints that are
applied to data characterized by the ontology.
[0011] In related aspects, the invention provides a digital data
processing system for information storage and retrieval as
described above in which the first digital data processor displays
a user interface (UI) for performing CRUD operations. In further
related aspects, the invention provides such a digital data
processing system in which the UI is based on the model and code
generated therefrom, e.g., by the first digital data processor
and/or the second digital data processor. In still further related
aspects, the invention provides such a digital data processing
system in which the UI includes a plurality of data fields, each
data field associated with one or more data labels (e.g., "SSN")
and one or more data values (e.g., "0000000000").
[0012] In related aspects, the invention provides a digital data
processing system for information storage and retrieval as
described above in which the set of constraints include, for
example, security rules (e.g., denying or allowing selected CRUD
operations), validators (e.g., defining a minimum and/or maximum
length for a data value, defining permissible data value character
types), default values (e.g., "0," NULL, etc.), field masking
(e.g., only transmitting the last 4 digits of a social security
number for display in the UI).
[0013] In related aspects, the invention provides a digital data
processing system for information storage and retrieval as
described above in which the data labels are defined by the
ontology and the data values are defined by any of the model (e.g.,
according to a default value constraint), and the first digital
data processor (e.g., in response to a CRUD operation performed via
the UI).
[0014] In related aspects, the invention provides a digital data
processing system for information storage and retrieval as
described above in which the second digital data processor masks a
selected portion of one or more data values prior to generation and
display of the UI on the first digital data processor, wherein said
masking is based on one or more constraints defined in the model.
In further related aspects, the invention provides a digital data
processing system for information storage and retrieval as
described above in which the first digital data processor generates
a UI that displays portions of the data values that are not masked,
and does not display the masked portions of said data values.
[0015] In related aspects, the invention provides a digital data
processing system for information storage and retrieval as
described above in which the first and/or second digital data
processors generate a warning in response to user-input entered via
the first digital data processor. In further related aspects, the
invention provides a digital data processing system as described
above in which the warning is generated in accord with the one or
more constraints defined by the model (e.g., minimum or maximum
data value length). In still further related aspects, the invention
provides a digital data processing system as described above in
which the first digital data processor displays said warning to a
user and/or administrator.
[0016] In related aspects, the invention provides a digital data
processing system for information storage and retrieval as
described above in which the second digital data processor displays
a UI for defining the constraints of the model. For example, the UI
may include a serious of menus, check boxes, fields, etc., for
creating, customizing, and associating security rules, default
values, validators, and field masking constraints with data
characterized in the ontology.
[0017] Still other aspects of the invention provide methods
paralleling the operations described above.
[0018] These and other aspects of the invention are evident in the
drawings and text that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] A more complete understanding of the invention may be
attained by reference to the drawings, in which:
[0020] FIG. 1 depicts a digital data processing system and
environment of the type used in practice of the invention;
[0021] FIGS. 2A-2E depict developer-side user interface (UI)
displays, e.g., for defining a digital data storage and retrieval
system that provides CRUD capabilities;
[0022] FIGS. 3A-3E depict client-side user interface (UI) displays,
e.g., for performing CRUD or other digital data storage and
retrieval operations; and
[0023] FIG. 4 depicts an operation of a system for storing and
retrieving digital data (e.g., RDF data or otherwise) according to
one practice of the invention.
DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT
[0024] FIG. 1 depicts a digital data processing system and
environment for storing and retrieving digital data (e.g., RDF or
other semantic data) according to one practice of the invention.
This can include, for example, creating, reading, updating and
deleting (CRUD) data from a data store via a Graphical User
Interface (GUI), or other User Interface (UI), e.g., command-line,
etc. In the illustrated embodiment, the system includes digital
data processors 20-50, which may be personal computers,
workstations, mainframes, or other digital data processing
apparatus of the type known in the art capable of executing
applications, programs and/or processes. Although digital data
processors 20-50 are shown here, those skilled in the art will
appreciate that in other embodiments the system may include a
greater or lesser number of such digital data processors.
[0025] Illustrated digital data processors 20-50 execute in a
network environment. In other embodiments, digital data processors
20-50 may operate alone or in other environments, networked or
otherwise. In any event, illustrated digital data processors 20-50
are coupled to each other, as shown, via a network 70, such as the
Internet, a local-area network (LAN), wide-area network (WAN), or
otherwise, that may be public, private, IP-based, etc.
[0026] In a typical embodiment, illustrated here, digital data
processor 20 comprises a personal computer, workstation, mainframe,
or other digital data processing apparatus, as discussed above, and
is used by a developer or analyst (collectively, "analyst), to
build, test, and deploy a software platform providing CRUD editing
capabilities to a client 30, as discussed further below. The
digital data processor 20 executes a variety of applications for
creating such a platform, including, for example, an ontology
editor 21 and a semantic editing framework (SEF) 23. The
illustrated ontology editor 21 creates an ontology 22 (e.g., either
automatically or via analyst input) that defines a structure of
data (e.g., RDF data stored in data store 60, discussed below).
This may include a text editor, an interpreter/compiler, libraries,
or otherwise--all of the type known in the art, albeit as adapted
in accord with the teachings hereof. In the illustrated embodiment,
the editor 21 creates the ontology 22 with the Web Ontology
Language (OWL), although in other embodiments the editor 21 may use
other ontology-definition languages, as well.
[0027] The illustrated SEF 23 defines (e.g., via analyst input)
user roles (e.g., Supervisor, Analyst, Administrator, etc.),
security rules, validators, default values, field masking, and/or
other constraints 24 (collectively, "constraints") that are applied
to data characterized by the ontology 22. In the illustrated
embodiment, the constraints 24 are defined in XML, although in
other embodiments it may be otherwise. The SEF 23 generates a
semantic model 25 (or simply, "model") by combining the ontology 22
and constraints 23 into a cohesive file (or set of files).
Accordingly, in the illustrated embodiment, the model 25 is the
"foundation" for providing CRUD capabilities to the client 30, as
discussed further below. The SEF 23 also generates client code 26
(e.g., Adobe Flex) for creating the client interface 31, and the
database code 27 which facilitates interaction between the digital
data processor 50 (discussed below) and the data store 60
(discussed below).
[0028] Illustrated digital data processor 30 comprises a personal
computer, workstation, mainframe, or other digital data processing
apparatus, as discussed above, and is used by a client to interface
with stored data (e.g., RDF or otherwise). In the illustrated
embodiment, the client 30 provides an interface 32 (e.g., graphical
or otherwise) for interacting with data in the data store 60. By
way of non-limiting example, the client 30 provides operations for
creating, reading, updating and/or deleting data (CRUD) in the data
store 60, although the client 30 may provide other operations, as
well. In the illustrated embodiment, the interface 32 is generated
from UI code 33 comprising the client code 26, HTML, and other web
technologies known in the art, such as JavaScript, etc, although in
other embodiments it may be otherwise.
[0029] The digital data processor 40 (or "UI server) comprises a
personal computer, workstations, mainframe, server, or other
digital data processing apparatus. In the illustrated embodiment,
the digital data processor 40 generates the UI code 33 that
displays the UI 32 on the client device 30. In the illustrated
embodiment, the data processor 40 generates the code 33 from the
model 25 and the client code 26, and comprises a combination of
Adobe Flex code, and HTML, JavaScript, XML, etc., although it may
also include other components instead of, or in addition to the
aforementioned technologies (e.g., programming libraries, modules,
etc.). Although in the illustrated embodiment, the data processor
40 generates the UI code 33, in other embodiments the data
processor 20 may generate such code 33 itself, e.g., via the SEF
23, and the data processor 40 may only store and execute that code
33 without the model 25.
[0030] As discussed above, the digital data processor 40 executes
in a network environment, e.g., in communications coupling with
digital data processors 20-30 and 50 via the LAN/WAN 70. In the
illustrated embodiment, the digital data processor 40 executes
behind one or more firewalls 41 and 42 of the type conventionally
known in the art of digital network security. The firewalls 41 and
42 themselves may comprise software executing on the digital data
processor 40, or they may execute on dedicated appliances (e.g.,
one or more digital data processors). In any event, the firewalls
41 and 42 regulate traffic between and among the digital data
processors 20-50, e.g., in order to prevent unauthorized access to
the digital data processor 40. Thus, for example, the firewalls 41
and 42 may be configured by the analyst to permit, deny, encrypt,
decrypt, or proxy network traffic between different security
domains based upon a set of rules and/or other constraints (e.g.,
as defined in the model 25, or otherwise). Although firewalls are
shown here, those skilled in the art will appreciate that systems
according to the invention may employ a wide range of security
measures of the type commonly known in the art of information
security (e.g., physical security, authentication systems,
anti-virus software, etc.), albeit as adapted in accord with the
teachings hereof.
[0031] The illustrated digital data processor 50 (or "Database
Server") comprises a personal computer, workstation, mainframe,
server, or other digital data processing apparatus, that executes a
digital data information storage and retrieval application (e.g., a
database management system). The data processor 40 stores,
retrieves, updates, deletes, and otherwise interfaces with data
maintained on networked attached storage device 60. In the
illustrated embodiment, the data store 60 comprises a hard disk
drive and/or other persistent storage device of the type known in
the art. By way of non-limiting example, the storage device (or
"data store") 60 stores data (e.g., RDF or otherwise) for retrieval
and display by the digital data processors 30 and 40.
[0032] FIG. 2A-2E depict an exemplary user interface display 100
for the SEF 23 that allows a user (e.g., analyst, developer,
administrator, etc.) to create, customize and associate the
constraints 24 with the data characterized in the ontology 22. In
the illustrated embodiment, the SEF 23 will generate the model 25,
and the code associated therewith (e.g., client code 26, database
code 27, etc.), from the ontology 22 and constraints 24. In other
embodiments, a user may bypass the SEF display 100 altogether and
manually code the constraints 24 to add or customize constraints as
necessary. FIG. 2A-2E further depict exemplary code "snippets" 22a
and 24a from the ontology 22 and constraints 24 which reflect a
current display state of the UI 100. More particularly, as
constraints are added, as illustrated in FIGS. 2A-2E, the
constraints file 24a is updated to contain the SEF-generated code
for those constraints. Associated FIGS. 3A-3E depict exemplary
client user interface displays 32 corresponding to the SEF
interface displays 100 of FIGS. 2A-2E. More specifically, FIG. 3A
corresponds to FIG. 2A, FIG. 3B corresponds to FIG. 2B, and so on
and so forth.
[0033] By way of overview, the ontology 22 is defined with OWL, as
mentioned above, a portion of which is shown here (22a). OWL uses
an RDF/XML syntax to define a set of "classes" (e.g., "Person")
that each have assigned "properties" (e.g., "SSN"). However, those
skilled in the art will appreciate that classes and properties are
specific to an OWL implementation of the ontology 22, and in other
embodiments, the ontology 22 may be implemented otherwise.
[0034] Also as discussed above, and again by way of of overview,
the constraints 24 are defined in XML, a portion of which is shown
here (24a), although in other embodiments, the constraints may be
defined otherwise. Those skilled in the art will appreciate that
the ontology 22a, constraints 24a, and display 100 illustrated here
are shown only by way of example, and other embodiments may be
implemented otherwise (e.g., without properties or classes), or
without ontologies at all (e.g., the system may use another
semantic definition structure).
[0035] FIG. 2A, more particularly, depicts an exemplary SEF 23 user
interface 100 displayed on the digital data processor 20 used for
customizing and generating the model 25. In the illustrated
embodiment, shown here, an analyst may add, remove, update, or
otherwise define constraints via a set of graphical menus 110-170,
and the SEF 23 generates code 24a corresponding to those
constraints. As discussed above, and below, those constraints can
include, for example, default values 140, field masking 150,
validators 160, and security rules 170, just to name a few. Those
skilled in the art will appreciate that menus 110-170, as well as
the code 22a and 24a, are shown merely by way of example, and in
practice of the invention, the system may include many different
configuration options (e.g., pre-defined in the system package,
defined by a developer during the initial system deployment, and/or
by a client after the system has been deployed).
[0036] Although not illustrated here, the SEF 23 may also define
user roles (e.g., Supervisor, Analyst, etc.), and assign each role
a selected "privilege" level. By way of non-limiting example, a
Supervisor may have a higher privilege level than an Analyst. In
the illustrated embodiment, user roles are often associated with
constraints (e.g., security rules, field masking, etc.), as
discussed further below. Thus, by way of non-limiting example, the
SEF 23 may define a constraint that allows a Supervisor, but not an
Analyst, to perform update operations.
[0037] As shown here, by way of example, the display 100 is divided
into two regions (i.e., a top region and a bottom region). The top
region includes a property field 110, label field 120, and type
field 130. Those skilled in the art will appreciate that the
illustrated display 100 is shown merely by way of example, and
other embodiments may use a different display (e.g., an undivided
display, a display with three or more regions, etc.), or no display
at all (e.g., an analyst may edit the model directly by hand-coding
the constraints 22).
[0038] In the illustrated embodiment, the property field 110
displays the namespace and name of the selected property (e.g.,
"http:// . . . /#ssn," as shown by way of non-limiting example)
defined in the constraints 22a (e.g., via an analyst using the SEF
UI 100). The label field 120 comprises a configurable field used to
set the field name (e.g., "SSN," as shown by way of non-limiting
example) that will display on the client interface 32. The type
field 130 is a configurable field (e.g., via a "drop down"
selection box, as shown) that sets the data type of the field,
e.g., "string" (as shown by way of non-limiting example), boolean,
data, or float, just to name a few. In the illustrated embodiment
the type field 130 is typically populated from the ontology 22, but
it may also be manually set, e.g., by the analyst. Those skilled in
the art will appreciate that fields 100-130 are shown by way of
example, and in practice may include other fields, selection boxes,
checkboxes and otherwise, e.g., as specified by the ontology 22,
constraints 24, or otherwise.
[0039] The bottom region of display 100 provides configuration
menus for defining the constraints 24. The display 100 includes a
default factory menu 140, data processor menu 150, validator menu
160, and security rules menu 170, although in practice of the
invention, a greater or lesser number of menus may be displayed. As
shown in FIG. 2B, by way of non-limiting example, the user has
chosen to constrain the property "http:// . . . #ssn" having the
label "SSN" as having a "string" value. Also as shown, the SEF 23
has generated the corresponding code 24 for that constraint. Again,
the display 100 and constraint code 24a are shown by way of
non-limiting example and may vary in practice (e.g., the generated
code may be in a markup language other than XML, etc.).
[0040] FIG. 2B depicts the display 100, generally as described
above, further including a default factory constraint 141 defined
in the default factory menu 140. The default factory constraint 141
effectively sets a static default value for a selected property
(e.g., "http:// . . . #ssn"). More specifically, the constraint 141
specifies that the selected property has a fixed default value,
e.g., "000000000." The SEF 23 will subsequently generate the code
24a that will instruct the client 30 to display a default value of
"000000000" for this property in the corresponding field 32a of the
UI 32. See FIG. 3B. Those skilled in the art will appreciate that
in practice of the invention, other default values may be defined
instead of, or in addition to, the illustrated default value, shown
by way of non-limiting example.
[0041] FIG. 2C depicts the display 100, generally as described
above, further including a data processor 151 defined in the data
processor menu 150. The specified data processor 151 applies a
character masking constraint to the selected property (e.g.,
"http:// . . . #ssn"). In the illustrated embodiment, selecting
"mask" instructs the SEF 23 to generate code that, when executed by
the digital data processor 40 (or other apparatus that generates
the UI 32), will hide the property's value in the UI 32 and enter a
mask character that will display in the UI (e.g., an asterisk). See
FIG. 3C. Properties can be assigned a number of different masking
settings that will be applied based upon the role assigned to the
user viewing the field. By way of non-limiting example, a data
processor could be defined to allow a "supervisor" to see more of
data (e.g., a social security number) than an "analyst," or to mask
additional characters when performing an specific operations.
[0042] Generally, masking is performed by entering into the UI 100
the number of characters that should be masked at the start and end
of the selected field, and by selecting the role(s) that the mask
should apply to. In the illustrated embodiment, a blank start
and/or end values are assumed as zeroes, and a blank role entry
will apply the mask to all roles, although in other embodiments it
may be otherwise. Moreover, if a user's role matches multiple
entries in the list of masks for a selected property, then the
first mask in the list will be applied. In the illustrated
embodiment, masking is based on the role of the user, and that the
system will always mask according to the most restrictive role
added, although in other embodiments this may vary.
[0043] Those skilled in the art will appreciate that in practice of
the invention, other data processors may be defined instead of, or
in addition to, the illustrated masking data processor, shown by
way of non-limiting example.
[0044] FIG. 2D depicts the display 100, generally as described
above, further including a validator constraint 161 defined in the
validator menu 160. In the illustrated embodiment, the constraint
161 allows a user to create an integer definition for validation
that can be set with minimum or maximum values for a selected
property. Thus, as shown by way of non-limiting example, the
selected property (e.g., social security number) must have a
minimum length of nine characters and maximum length of nine
characters, i.e., effectively requiring a nine-digit entry. By way
of further example, the SEF 23 will generate code 24a that, when
executed by the digital data processor 40, will instruct the client
30 to display a UI 32 that requires a nine-digit entry in the
selected property field 32a. See FIG. 3D. Those skilled in the art
will appreciate that in practice of the invention, other validators
may be defined instead of, or in addition to, the illustrated
validator, shown by way of non-limiting example.
[0045] FIG. 2E depicts the display 100, generally as described
above, further including a security rule constraint defined in the
security rules menu 170. In the illustrated embodiment, a security
rule can be set by user role and/or by operation (e.g., create,
read, update, delete, etc.). As shown, by way of non-limiting
example, a user can define a constraint (e.g., via pop-window 171
or otherwise) that specifies that Analysts are not allowed to
perform update operations. By way of further example, the SEF 23
will generate code 24a that, when executed by the digital data
processor 40, will instruct the client 30 to display a UI 32 that
will not allow Analysts to perform update operations. See FIG. 3E.
Those skilled in the art will appreciate that in practice of the
invention, other security rules may be defined instead of, or in
addition to, the illustrated security rule, shown by way of
non-limiting example.
[0046] FIGS. 3A-3E, referenced above, depict a user interface (UI)
32 executing on client digital data processing device 30 (e.g.,
personal computer, workstation, etc.). In the illustrated
embodiment, the client device 30 provides a user interface 32 for
interacting with stored digital data (e.g., data create, read,
update and delete operations, and so forth). As shown, the user
interface 32 includes a variety of fields, e.g., "SSN" field 32a,
discussed above, and several "buttons" 32b-32e for performing
"CRUD" operations (e.g., via HTTP methods, RPC, or otherwise).
Although user interface buttons are only included for data create
32b, read 32c, update 23d and delete 32e operations, those skilled
in the art will appreciate that in practice of the invention the UI
32 may include other interface options instead of, or in addition
to, the interface buttons shown here by way of non-limiting
example.
[0047] FIG. 4 depicts an exemplary operation of a system for
storing and retrieving digital data (e.g., RDF or other semantic
data) according to one practice of the invention. The illustrated
sequence of steps is just one of many with which the invention may
be practiced. Thus, it may be practiced with a greater or lesser
number of steps than those shown here, ordered as shown in the
drawing or otherwise.
[0048] By way of overview, as discussed above, a system executing
in accord herewith stores and retrieves digital data (e.g., RDF or
other semantic data) in accord with a model 25, or, more
particularly, in accord with an ontology 21 (e.g., defined via the
ontology editor 21) and a set of constraints 24 (e.g., defined via
the SEF 23). This storing and retrieving of digital data can
include, for example, creating, reading, updating and deleting
(CRUD) data from a data store 60 via a Graphical User Interface
(GUI) 32, or other User Interface (UI), e.g., command-line,
etc.
[0049] Unlike other data storage and retrieval systems currently
available in the prior art (e.g., in which developers APIs supplied
with the systems to write "one-off" applications), the system of
the illustrated embodiment allows a user 20 (e.g., developer,
analyst, etc.) to create a model 25 that defines how user's (e.g.,
client 30) interact with data (e.g., RDF data in data store 60).
Thus, for example, as client requirements change (e.g., increased
security on UPDATE operations), the user may easily edit the model
25, rather than having the original developers either extensively
modify the existing application, or write an entirely new
application from scratch.
[0050] FIG. 4 depicts a sequence of steps for performing storage
and retrieval operations (e.g., CRUD operations, etc.) in a system
according to the invention. In steps 400-430, a developer,
administrator, analyst, etc. (collectively, "analyst") builds and
deploys a software platform providing CRUD editing capabilities to
a client, as discussed above. More particularly, in the illustrated
embodiment, an analyst executes the ontology editor 21 (e.g., on
the digital data processor 20 or otherwise). See step 400. The
illustrated ontology editor 21 creates an ontology 22 that defines
a structure of data (e.g., RDF data stored in data store 60,
discussed below). This may include a text editor, an
interpreter/compiler, libraries, or otherwise--all of the type
known in the art, albeit as adapted in accord with the teachings
hereof. In the illustrated embodiment, the editor 21 creates the
ontology 22 with the Web Ontology Language (OWL), although in other
embodiments the editor 21 may use other ontology-definition
languages, as well.
[0051] In step 410, the analyst executes the SEF 23 (e.g., on the
digital data processor 20, or otherwise) to define user roles
(e.g., Supervisor, Analyst, Administrator, etc.), security rules,
validators, default values, field masking, and/or other constraints
24 (collectively, "constraints") that are applied to data
characterized by the ontology 22. In the illustrated embodiment,
the constraints 24 are defined in XML, although in other
embodiments it may be otherwise. The SEF 23 generates a semantic
model 25 (or simply, "model") by combining the ontology 22 and
constraints 23 into a cohesive file (or set of files). Accordingly,
in the illustrated embodiment, the model 25 is the "foundation" for
providing CRUD capabilities to the client 30.
[0052] In step 420, the SEF 23 generates and transmits database
code 27 to the database server 50. In the illustrated embodiment,
the code 27 facilitates interaction between the database server 50
and the data store 60. In step 430, the SEF 23 generates and
transmits the client code 26 (e.g., Adobe Flex) to the UI Server 40
for creating the client interface 31 displayed on the client device
30 (e.g., via a web browser), although in other embodiments, the
code 26 may be transmitted directly to client device 30.
[0053] In the illustrated embodiment, as discussed above, the SEF
23 displays a user interface 100 for the analyst to customize and
generate the model 25. More particularly, the analyst may add,
remove, update, or otherwise define the constraints 24 via a set of
graphical menus 110-170, and the SEF 23 generates code 24a
corresponding to those constraints. As discussed above, those
constraints 24 can include, for example, default values 140, field
masking 150, validators 160, and security rules 170, just to name a
few.
[0054] In step 440, the client device 30 sends a request to the UI
server 40 for an interface 32 (e.g., a web page) for interacting
with data in the data store 60. By way of non-limiting example, the
client 30 may request a web page that provides form-fillable fields
and graphical buttons for performing CRUD operations, although the
client 30 may request other interfaces, as well (e.g., a log-in
screen, etc.). In the illustrated embodiment, the interface 32 is
generated from UI code 33 comprising the client code 26, HTML, and
other web technologies known in the art, such as JavaScript, etc,
although in other embodiments it may be otherwise.
[0055] In step 450, the UI server 40 generates the UI code 33 that
will display the UI 32 requested in step 440. In the illustrated
embodiment, the UI server 40 generates the code 33 from the model
25 and the client code 26, and comprises a combination of Adobe
Flex code, HTML, JavaScript, XML, etc., although it may also
include other components instead of, or in addition to, the
aforementioned technologies (e.g., programming libraries, modules,
etc.). Although in the illustrated embodiment, the UI server 40
generates the UI code 33, in other embodiments the data processor
20 may generate such code 33 itself, e.g., via the SEF 23, and the
UI server 40 may only store and execute that code 33.
[0056] In step 460, the UI server 40 sends the UI code 33 to the
client 30 (e.g., via LAN/WAN 70), and the client 30 renders the
user interface 32 (e.g., a web-fillable form with blank data
fields) from that code 33. Those skilled in the art will appreciate
that one or more firewalls 41 are employed to insure that the UI
code 33, or other data, is not intercepted (e.g., by hackers,
sniffers, etc.). Moreover, to further insure system security and
integrity, in the illustrated embodiment only necessary code and
data is sent to the client, e.g., as defined by the model 25,
discussed above. Although not shown here, in other embodiments, the
system may employ additional firewalls or other security measures
commonly known in the art of information security, albeit as
adapted in accord with the teaching hereof.
[0057] In step 470, the client sends a data identifier (e.g., a
record identifier) to the UI server 40 for processing by the UI
server 40 and/or database server 50, as discussed below. By way of
non-limiting example, the data identifier may be a "Customer ID"
that has data attributes (e.g., last name, date of birth, height,
social security number, etc.) associated with fields of the
interface 32. In step 480, the UI server 40 sends a transaction
request to the database server 50 to retrieve data associated with
the identifier from the data store 60. In step 490, the database
server 50 processes the request of step 480 and retrieves the data
from the store 60 (e.g., via SQL, SPARQL, etc.). In steps 500-510,
the retrieved data is sent to the UI server 40 and then to the
client 30 for display in the UI 32. See, for example, FIG. 2A.
[0058] In step 520, the client 30 inputs data and initiates a
selected CRUD operation (e.g., via the user interface 32). For the
purposes of this discussion, we will assume that the interface 32
looks similar to that illustrated in FIGS. 2A-2E, and the user
wishes to input a social security number data value into a social
security number data fields (i.e., perform a data create
operation). However, those skilled in the art will again appreciate
that these steps are shown merely by way of non-limiting example,
and may include other steps in addition to, or instead of, the
steps discussed above (e.g., other CRUD operations may be
performed, other data values may be input/edited, etc.).
[0059] In step 530, the client 30 performs a "client-side"
validation on the data inputted in step 520. In the illustrated
embodiment, client-side validations are executed by the UI code 33,
and are defined in the client code 26, although in other
embodiments they may be executed and/or defined otherwise (e.g., in
the model 25). By way of non-limiting example, client-side
validations can include, among others, the constraints discussed
above (e.g., minimum string length, maximum string length, etc.),
and if any validation fails, the user is warned, e.g., via a pop-up
window displayed in the UI 32 or otherwise. Thus, for example, if
the client code 26 required a validation that a social social
security number data value must have a minimum and maximum
character length of nine characters, and the user failed to input a
nine-character social security number data value, the user would be
warned (see, e.g., FIG. 3D), and prompted to re-enter the number.
This process will be repeated until all validations are passed.
Those skilled in the art will appreciate the above example is just
that--an example, and in practice of the invention other
validations may be performed in addition to, or instead of, the
validation described above.
[0060] In step 540, the inputted data (e.g., the social security
number in this example), is sent to the UI server 40 (e.g., via
LAN/WAN 70) for "server-side" validations (step 550). As discussed
above, these validations are defined in the model 25 and executed
by code generated therefrom by the UI server 40. They can include,
for example, a check to insure that the social security number is a
string containing exactly nine digits (e.g., in the event that such
an error was not caught by the client-side validations in step
530). By way of further example, if the inputted data does fail
this validation, or any other validations (e.g., as defined by the
model 25 or otherwise), the UI server 40 may generate a server-side
exception which can, for example, terminate the current
transaction, or it can be sent to the client 30 in the form of a
graphical warning (see step 560).
[0061] In step 560, a warning is sent from the UI server 40 to the
client 30 if an exception (or other type of error) is thrown or
detected in the validation step 550. By way of non-limiting
example, such an error can be generated as a result of an inputted
social security number that is not exactly nine digits in length
(e.g., as described above in step 530), or as otherwise required by
the model 25. In the illustrated embodiment, the warning can be a
pop-up window (e.g., of the type shown in FIG. 3D), etc. In step
570, the client can re-input data (e.g., a new social security
number data value) that will be re-validated in step 580 (e.g., as
described above in step 550). This process will be repeated until
the validation step 580 is successfully completed (i.e., without
any detected exceptions or errors).
[0062] In step 590, the validated data (e.g., the new social
security number data value) is sent to the database server 50 for
processing (e.g., via a LAN/WAN connection, cabled connection,
etc.). In step 600, the database server 50 processes the
transaction, e.g., associates the inputted data value with the
social security number attribute of the data identifier (e.g.,
Customer ID "555555") in the data store 60. This can be
accomplished by a variety of techniques pursuant to the data format
of the store 60. Thus, for example, SPARQL may be used for an RDF
data store, SQL for a relational database, and so forth. In this
example, the code (whether SPARQL, SQL, etc.) for associating the
inputted data value with the social security number attribute of
the specified data identifier (e.g., Customer ID "555555")
comprises the code 27 generated by the SEF 23 (as discussed above
and shown in FIG. 1) and stored/executed on the database 50, (as
discussed above and shown in FIG. 1), although in other embodiments
it may be otherwise.
[0063] In step 610, the database server 50 returns the the result
of the processed transaction (e.g., completed, failed, etc.) and
the processed data (e.g., a confirmed created data value, a
confirmed updated data value, etc.) to the UI server 50. In the
illustrated embodiment, failed transactions generate a warning by
the database server 50 or UI server 40 (e.g., as described in step
560) that can be sent to the client 30, administrator, other user,
etc.
[0064] In step 620, the data (e.g., social security number) is sent
to the client 30 for display in the UI 32, subject to any
constraints defined by the model 25. Thus, as shown here by way of
non-limiting example, a masking constraint may be applied to the
social security number data value before it is sent to the client
30 for display in the UI 32. In the illustrated embodiment, masking
will hide a selected portion of the data value (or the entire data
value) on the UI server 40 (i.e., "server-side" masking), and the
full data value (e.g., social security number) will never be sent
to the client 30 or be displayed in the UI 32. Rather, the UI
server 40 will replace selected portions (e.g., one or more
characters) of the data value with mask values for display in the
UI 32 (e.g., an asterisk for each of the masked characters in the
data value). See, e.g., FIG. 3C. Of course, those skilled in the
art will appreciate that other types of masking may be applied in
this step, as well as other constraints in addition to, or instead
of, masking constraints.
[0065] Described above are methods and apparatus meeting the
desired objectives. Those skilled in the art will appreciate that
the embodiments herein are merely examples of the invention and
that other embodiments incorporating changes therein fall within
the scope of the invention, of which we claim:
* * * * *