Re: Proposal: Uniform Handling of User Data

[Martyn Russell <martyn lanedo com>]

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 it

Tracker 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?

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell