This is a read-only archive of the inkscapeforum.com site. You can search for info here or post new questions and comments at I will use this thread to discuss the controversial concept of using SVG-XML languages to create a graphic database.
Database: A collection of data stored on a computer storage medium, such as a disk, that can be used for more than one purpose. Dictionary of Computer Terms ISBN 978-0-7641-4755-5
Of course not all databases are "relational databases."
Think of the photographer's database which stores his photographic job. These are basically modern versions of contact sheets. They are data storage systems - they can sort files by image size, perhaps meta data, color curves and by other parameters - but, the real data being stored is the image itself.
Photographers and artists in general use "graphic databases."
Obviously, computers do not understand the meaning of data.
In relational databases, the computer only sees a string of Unicode elements.
Any one string is placed and perhaps compared to other strings.
When the appropriate string, as desired by the human user, is found - it gets displayed.
That is really all a database is. A place to store, organize and present data for interpretation by the human users of that data. Searching for relationships among data is important in relational databases. Not all databases are required to do this.
In graphical databases, the computer only sees a group of elements.
Any one element is placed and perhaps compared to other elements - by the human viewer of the database as an end product.
Sometimes, these graphic elements can even be compared in relation to other graphic elements - eg looking at bright spots in a photograph to detect new stars.
When the appropriate elements, as desired by the human user, are found - they get displayed.
A graphic database - like the contact sheet - is a place to store, organize and present data for interpretation by the human users of that data.
So, how would SVG - XML be used to create this "Graphic Database?"
Consider the animation I discuss in my other post ( will edit with precise reference ) See NELCHAI'S MEMORY ENHANCEMENT.
The monkey is rotoscoped in inkscape. The original images of that monkey are greyed out and presented behind the monkey as a composite whole in the animation.
How would the database I propose work?
To mitigate the headaches of very large memory files - each file would offer a reasonable memory cap.
That memory cap would be defined by the file's < load - close > cycle time.
Say a segment of the animation takes a second to upload. The previous file would need to hold enough memory ( played as the SVG animation ) to facilitate the loading of the next file ( another part of the same SVG animation ) without an apparent seam in the sequence. No stutters, no continutity breaks etc. The system ( database ) would be loading the files ( sets of svg elements and data ) in sequence without revealing itself to the end-user-viewer.
In this way, a collection of SVG files which are opened and closed in sequence by a management system becomes a database.
But there can be a lot more to it than just an automated method for opening and closing files.
Let us say that the end-user-viewer's computer system contains their personal profile - which they themselves populated.
This is a concern for artists who specialize in VISUALIZATION.
What if the viewer of the website - or a display screen on a tablet - or a digital blackboard - or other display device is red-green color blind. What if they are dyslexic? What if they simply have difficulty with the more "complex" typefaces? What if they are reading the screen under military red lights? etc
The individual user's profile can drive their experience with the data presented to them through the SVG-XML database which I propose.
The system - database - simply opens appropriate files and then turns on and off layers previously designed and stored in the SVG editor by the artist working on the project. ( this is the concept in a nutshell )
A sentence, presented as a graphic, is an element within an SVG file.
An employee's name is an element within a database file.
SVG elements are stored in files.
Employee data is stored in a file.
Databases manage these file collections that they may be used for more than one purpose.
The system reads the end-user-viewer's profile
The system would turn off the standard background imagery which is a green forest.
The system would turn on the artist's alternative option which accents the deep blue sky and violet shadows present in the image.
The problem of being red-green color blind has been mitigated by the artist - and - the customer's interest has still been seized on behalf of the product.
OR
The system would read their profile
The system would see that they do not like the complex typeface so it is converted into something simple such as century schoolbook
The artist has entered this typeface - and presented an artistic treatment of it - as an integrated part of the svg file.
The system turns off the first typeface and turns on the other. - This is the same as a relational database which presents John's file when it is desired rather than Mary's
Additionally, because there is a border which ends 10 pixels from the right end of the typeface - the computer automatically relocates the end of the border to stay 10 pixels from the text - The node position is relative to the location of the end of the text element.
With this method the problems of typeface complexity, dyslexia and possibly even language translation can be mitigated.
There is a lot more which can be done with this.
Consider that an SVG animation is not a true animation.
" There is no difference between a Bugatti and a Model A Ford - they both drive ya' to the grocery store"
Well, yeah, that is valid - in a certain kind a way - But I know a couple women who......
Artists consider animations by divisions of time. 24 frames per second - 48 frames per second as used for the Hobbit.
SVG animation is not divided into frames per second.
SVG "animation" is not even a video of an event because even video is shot at a frame per second rate.
SVG "animation" is actually SVG "reconstruction"
It is possible to create an SVG "Reconstruction" which presents the development of our solar system's planets and moons as they revolve and rotate around the sun. This SVG "reconstruction" can be linked to the clock of the computer to present a representation - or reconstruction - of precisely where the celestial items are right now. No inter-frame gap exists. No simulation bias exists. SVG Animations are actually SVG Reconstructions.
I know that it is not industry standard terminology - but, I think that referring to these as "Animations" is rather like comparing a Bugatti to a Model A Ford.
The opportunity this SVG "Reconstruction" concept presents is dynamism. Combine computerized randomness generation, with subtle color shifts, automated pans and tilts of the camera. A viewer could watch the same presentation all day every day for 50 years and NEVER see the exact same presentation twice.
This could very greatly elevate the appealablility of any data presentation.
What is needed?
1. This MUST be open source and freely available to everyone producing software. If it is owned by any one group - they can begin to mandate one language - religion - national pride - world view - etc - over the others. The goal is to lower some of the barriers preventing users from using their computers in the most effective, efficient and satisfying way possible. No one can own this!
2. A programming language which can create and control graphic data entries = SVG
3. A programming language which can organize and control the display of those graphic data entries = XML
4. An editor which can control the interaction between the graphic data entries ( SVG ) and the higher level processes ( XML ) which turn them off and on = Inkscape
5. A viewing system which is interactive, clean, simple and effectively presents the stored data without looking as though it is doing so. = needs to be created.
I know this does not exist right now. Neither did the light bulb until it was created. This needs to be created for an increasingly digital world.
Tanks
James
PS - of course the end-user-viewer only receives a copy of the functional files as they need to view them - they would not get a copy of the working files - the working files would need to be lockable that the user could access the data through the management system but not recreate or change the original data. ( until, we as a species transcend economics )
