Hi Martyn,
Excellent points. I didn't want to go into small details there, since that would make the message very long. On the other hand, I don't want to send people to read the whole tutorial. I'll try to clarify the points.
Assume you're a user, looking for a TODO desktop app. Tons of them exist, but you can't find one that meets your needs. Naturally, you have a unique mental model, while those apps - especially commercial ones - try to force their model on you. The same applies to other kinds of apps - you make like the calendar, but not the tasks. Maybe you like the mail GUI, but not the contact list.
Since the data model is static, you can't change it. Changing the model requires updates to the code. And even if only an ontology change is required, it means the app developers need to consult you and send you a patch for Tracker.
With my proposal, you can manage your data and your model in plain text, by yourself. As a user. You can even use my widgets, which allow you to dynamically choose fields and organize data in a table/treeview/graph/calendar. If you want to manage your data in plain text directly, it's easy. Can you manage a large hierarchy of tasks in RDF by hand? RDF is not designed for it, certainly not for users to do it. Under my proposal, you use an easy simple language to add your objects, even without any programming knowledge.
There's also the benefit of not needing an upstream ontology: You can just write you own model in seconds. It's easy for a user like its easy for you to create a new Python/C++/Vala class and add some data members (fields).
Of course, if apps want to integrate they have to use the same model, or at least matching models (e.g. derive classes, user the same properties or derived properties). It's more or less like RDF ontology creation process, but independent of the storage - no central model storage needs to exist. Adding ontologies to a backend (e.g. Tracker) can be transparent to app developers, and be done independently of the work on the models themselves.
With such a system, many apps - including Gnome apps - can very quickly start using Tracker as a storage backend, with the models and data being translated to RDF/OWL. Take all those 3rd party apps developed by one person, like TaskJuggler, gjots2, CherryTree and many others. They all would be able to semntic-desktop-ly integrate, almost on the fly.
I remember how much time and reading I needed before I understool how RDF words, and I'm still far from understanding it fully. The language I suggest is straight forward and simple. It's weaker than RDF in some areas, because its purpose and design are different, but it's very easy to write models and data with, including manual handling of them.
My proposal is somewhat "semantic desktop and data modeling for the masses". It's more than that if you count the widgets and the APIs. Think LibreOffice Base (or MS Access): Many non-programmers work with it, but it's based on tables, not graphs. My proposal allows to have a similar kind of app, but the classes and properties you define are not stored as tables, but as an interconnected semantic model, which can be stored in Tracker as RDF. Maybe this is one of the major differences and interesting uses of my proposal.
I hope it helps clarify things :-)
You can also take a look at the quick-start section of the tutorial. It demonstartes a common (expected) use case.
http://gitorious.org/peer-review/peer-review
Thank you for the input!
fr33domlover
:כתב Martyn Russell, 2013-08-28 09:42 בתאריך
On 27/08/13 15:32, fr33domlover wrote:On ג', 2013-08-27 at 16:00 +0200, Jens Georg wrote:On Di, 2013-08-27 at 13:46 +0200, fr33domlover mailoo org 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.NOTE: I am not shooting down your proposal, just trying to understand what hole you're filling here. -- Is there something missing with the Tracker front end then?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 itTracker has a pretty well defined ontology already. We accept patches too :)2. It requires that you understand what data should be in Tracker, understand how to work with a datastore, understand RDF, etc.I don't understand your point here. You're advocating everything Tracker does which is everything you said we need - so what is your actual point here? Applications on the desktop still need to understand how their data is stored, would have to understand RDF to use Tracker etc anyway.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.You really don't want someone else playing with your ontology. That leads to your app breaking. What you want is a combined agreed and well structured model that is agreed. I should add, Tracker is not about storing data, it's about storing metadata. The actual data shouldn't really be in the Tracker database. This line is fuzzy I will admit ;)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 will admit, we don't really have policies about what should be in Tracker and what shouldn't or how to update the ontology/develop it.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.Have you looked at Tracker? We have classes and properties of classes. We have subclasses too. I wonder what it is that is really missing there for you?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.That sounds like an implementation detail. Our ontology is pretty easy to read as a human and so by extension, so is the RDF ;) Clearly using RDF queries like: select ?d where { ?a a b ; c ?d } Is not as easy to understand as: select ?title where { ?artist a nmm:Artist ; nie:title ?title } :)Like I said, I don't intend to replace Tracker, but provide a frontend that everyone can easily use.There are other front ends for tracker already, Grilo, Folks, etc. If you're doing something generic, you might as well use libtracker-sparql. I still don't understand what you're adding (in value) by providing another front end. What do you do that Tracker/everything else doesn't?