On ג', 2013-08-27 at 16:00 +0200, Jens Georg wrote: > On Di, 2013-08-27 at 13:46 +0200, [email protected] wrote: > > And this is different from tracker in what regard?
Hello Jens, Tracker is a semantic data and metadata storage. Is can serve as a backend for the system I suggest. If you want your application to use RDF, you need to write ontologies for your data model and work with the complex processes of creating the data triplets, storing them and retrieving them. Once you learn how to use RDF and Tracker it's probably not difficult, but: 1. It requires a development of a high-quality reusable ontology, and good knowledge of how to do it 2. It requires that you understand what data should be in Tracker, understand how to work with a datastore, understand RDF, etc. Whether we like it or not, RDF is not adopted by small people. It's a tool for professional data modeling. What I suggest is a simple system (whose models can translate to RDF is necessary), a bit more limited than RDF but allows anyone to create their own model and share them on the web. Instead of developing complex models and trying to understand the needs of many Gnome modules, you create a model for your needs. Someone else can extend it easily by hand, and you won't even notice. It's meant to be used by everyone, easily and conveniently. Maybe if RDF had better tutorials and simple tools, it would get adopted faster, as there's no reason for apps to store semantic data in XML when Tracker is available. I don't know. But the truth is that many apps still use their own formats and schemas, and developer time is wasted on writing the file I/O procedures, every time again and again. I suggest to eliminate the problems. Also, non-Gnome apps can enjoy the simple modeling language and easily integrate with Gnome apps, even though they're not part of Gnome officially (as you probably noticed, many non-Gnome apps naturally tend to have integration issues). Another point is that RDF doesn't define fields of classes. The only way to restrict fields is to use OWL, i.e. another language you need to learn. In the system I suggest, it's built-in and you easily design a model without any skills or research. Knowing an OOP language is enough to understand the concepts. And another important point: RDF is designed to be machine-readable, not for humans. Turtle syntax makes things a bit easier, but in the system I suggest the language is *designed* to be edited by humans. It's extremely simple and intuitive, no ugly XML ever involved. Like I said, I don't intend to replace Tracker, but provide a frontend that everyone can easily use. > > > Hello Gnome contributors, > > > > > > > > Few months ago I came up with an idea, relevant to developers of any > > application software. I mentioned it somewhere here on the lists, got > > feedback, made changes and started coding it. > > > > > > > > Now I have a closer-to-final view of the project, and I'd like to > > suggest it here and hear what you think about it. It may be somewhat > > revolutionary, I hope not too much :-) I didn't find other good places > > to submit ideas and get feedback, so I decided to do it here. Busy > > people ignore long messages, so I'll try to make it short and simple > > (for more info contact me). > > > > > > > > THE PROBLEM: > > > > Many desktop apps need to work with data. Unlike helper utilities used > > by the application, the tools which control data are associated with > > real-world persistent information, and the information exists outside > > of the application. > > > > And yet, it is treated almost just like application utilities: Normal > > programming language classes are used for both coding utilities (e.g. > > I/O streams) and for the actual data (e.g. a Task class in a Todo > > app). When saving and loading the data, the developer needs to choose > > a format and work with libraries (e.g. XML, JSON, INI). > > > > > > > > In fact, programming languages are a too, of programming, not a tool > > for arranging data: Classes, functions, objects, etc. are suited for > > programming a flow of instructions which do useful work. Data is > > totally different in nature, and so data serialization formats and > > utilities were created, such as XML and RDF. > > > > > > > > The problem is that XML and RDF and other tools are not easy enough to > > use, and either they're not adopted, or adoption means a lot of extra > > programming work (e.g. many Gnome modules write complex procedures for > > working with XML). RDF requires a higher learning curve, and very few > > apps have Semantic Desktop integration, even though this area has been > > around for years. > > > > > > > > THE PROPOSAL: > > > > I suggest a uniform system which allows developers to work with user > > data easily. It's fast, simple, very easy to learn. The backend can be > > easily be replaced, e.g. save to file, save to semantic datastore, > > save to remove service. Semantic Desktop and translation-to-RDF can be > > made without changing application code. The data models can be written > > separately from application code. Thus data model design becomes very > > flexible and separate from code, allowing it to be done by > > non-programmers. > > > > > > > > How it works? There is a data-modeling language. Some kind of mix > > between Turtle and Python syntax, but the point is that it's extremely > > simple. Non-programmers can easily start using it. The language allows > > defining data types using primitive builtin ones (e.g. define ID type > > to be a 9-digit string), properties, classes and objects. I wrote a > > full tutorial already, but for people familiar with RDF, the concepts > > are related (but not exactly the same). > > > > > > > > A well-planned API exists, which allows developers to work with the > > data models. Instead of defining programming-language classes, the > > developer can use the model directly from code, or write thin > > convenience wrappers which delegate the work to the model management > > utility. > > > > > > > > Writing these models doesn't require any special skills. It's very > > easy using a text editor, but I plan to create a GUI too, so that > > complex professional models can be made easily. As a bonus, users can > > easily customize the models and make applications behave like they > > want them to, in a manner never seen before. Your TODO app doesn't > > implement certain Task properties? No problem, you can add them. > > > > > > > > Using special very-dynamic GUI widgets, it's possible for apps to > > respond to changes in the model, and allow some kind of "data > > programming" to be done by users and developers without changing > > application code. Translation of models to RDF and storage in > > databases can be made by the backend easily. > > > > > > > > This new way of handling data is very easy, and I expect applications > > can start using it much earlier than Semantic Desktop spreads, so apps > > will already be ready for full desktop integration, and enjoy the > > dynamic data models. > > > > > > > > > > > > > > > > There's a Gitorious repo containing a tutorial and more info about the > > language and proposal: > > > > http://gitorious.org/peer-review > > > > I'm writing the software in C++ (could port/move to C/GObject) and > > later I hope to add API bindings for higher-level app programming > > languages, Python being in high priority. But that's small detail, > > right now I'd like to hear comments, suggestions, ideas, etc. > > regarding the proposal. > > > > > > > > Thanks and regards, > > > > fr33domlover > > > > > > _______________________________________________ > > desktop-devel-list mailing list > > [email protected] > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
