On Sunday 13 January 2008 12:07:25 Evgeny Egorochkin wrote: > В сообщении от Sunday 13 January 2008 12:12:34 Mikkel Kamstrup Erlandsen > > написал(а): > > On 13/01/2008, Evgeny Egorochkin <[EMAIL PROTECTED]> wrote: > > > В сообщении от Saturday 12 January 2008 23:02:18 Mikkel Kamstrup > > > Erlandsen > > > > > > написал(а): > > > > On 12/01/2008, Evgeny Egorochkin <[EMAIL PROTECTED]> wrote: > > > > > В сообщении от Saturday 12 January 2008 01:05:38 Mikkel Kamstrup > > > > > Erlandsen > > > > > > > > > > написал(а): > > > > > > On 11/01/2008, Sebastian Trüg <[EMAIL PROTECTED]> wrote: > > > > > > > Just my 2 cents: > > > > > > > Soprano has a IMOH very good DBus API [1] for RDF storage which > > > > > > > fulfills all 3 of your requirements below. We already use it > > > > > > > for Nepomuk and it works great. And since Xesam is already > > > > > > > using URIs to identify stuff why not go the extra mile to RDF > > > > > > > storage altogether? > > > > > > > > > > > > I thought Soprano depended on Qt? > > > > > > > > > > This is not a dependency that you can't easily get rid of. > > > > > > > > > > > Anyways, I don't think the RDF quadruples is a good thing to > > > > > > expose directly to the programmers who just want a quick and > > > > > > dirty metadata storage. It is simply just too technical. That > > > > > > does not mean that we cannot use that stuff under the hood > > > > > > though. > > > > > > > > > > Which part of ( URI, property name, property value , timestamp ) > > > > > programmers can't understand and why should it be hidden? > > > > > > > > Exactly my point :-) ( URI, property name, property value , > > > > timestamp ) is fine, but exposing the general Named Graph terminology > > > > (and features) > > > > > > Actually there's nothing more to named graphs than another element > > > added to the triple. So you can differentiate named graphs with > > > namespacing like mtime:/ uri. Using name graphs only for mtime might > > > backfire in the sense that named graphs could be used in other ways > > > like to store provenance info(where speicifc triple came from). > > > > That is exactly one problem I have with named graphs. It seems kind of > > arbitrary to allow exactly one "name" per graph. It kind of begs you > > to stick on XML blob in it with both mtime, provenenance, and your > > shoe size in centimeters. > > You're right in the sense that quads are arbitrary. Any information > represented with quads can be as well represented with triples, but a much > larger number of them. So quads are basically a slight relaxation of the > absolute minimalism of triples, which often is benefical in practice. > > It is also possible to use a xml blob. The question is whether this is > needed or not. > > > > > in the API is too generic to my taste. If we say that the > > > > triple name is always a timestamp I am ok with it. > > > > > > Actually generic API is the only one that's really needed, because it > > > is the most powerful. This doesn't exclude having a set of convenience > > > functions to do typical queries or even completely hide the RDFish and > > > SPARQLish nature of the matter for certain users of the technology. > > > > The most powerful and generic API is not always the right one to > > expose. You have to design the API so that the consuming programs also > > get a lot of expressive power and clarity. That is rarely a quality of > > totally generic interfaces. > > I didn't say you shouldn't expose simpler/specialized apis. I said it makes > no sense to intentionally disallow access to the most generic API. > > > Consider the following lines of code could be the same: > > > > double val = item.getValue(); > > double size = shoe.getShoeSize(); > > However for a code that deals with T-shirts, item.getValue() is better than > shoe.getShoeSize(). > > > If you are writing stuff that should really be generic (ie a generic > > RDF backend) then 1 is fine. If you are writing an application to > > manage a shoe store 2 would likely make things a lot clearer. Ofcourse > > this example is exaggerated, but I think the idea is clear. > > If your application is managing a shoe store but uses RDF as a backend, > it's unreasonable to completely disallow the access to RDF interface. > > > Our target is "Metadata Storage for the Desktop". Not "Generic Named > > Graph Storage" and our API should reflect this. > > Metadata Storage for the Desktop is just as ambiguous as a Generic RDF > Backend. > > What metadata are we talking about? Settings? Annotations? How about > external data sources like IMAP or a FOAF provided by a social networking > site? Where do we draw the line and should we?
Exactly. IMHO metadata on the desktop has a very wide and open range. Thus we need a pretty generic API. We can always add additional convenience stuff that handles most every-day uses but having something generic is not a bad idea. And the Soprano API could also provide just a starting point. If we can come up with some restrictions, we can include them and define some generic behaviors that the API should follow. > > If absolute generic'ism was the best thing in the world all APIs would > > consist of var arg functions: > > > > Object get (Object obj, ...) > > Object set (Object obj, ...) > > That's exactly what template metaprogramming and similar approaches are > doing, with some success mind you. > > As to specific/niche APIs, ontology is exactly the solution for this. RDF > backend is generic, but specific ontology consisting of classes and > properties provides human-friendly solutions for specific problems. > > If you use a generic RDF backend doens't mean you really have to operate in > RDF realm. You still can use constructs like: > > int length = aMessage.getLength() > > Unless your programming language can't feasibly support such constructs of > course. > > Soprano is a generic RDF backend, still you get to manipulate high-level > objects defined by an ontology and not RDF triples or anything low level > like this(unless you really want to). > > Yet Soprano is not tied to any specific ontology, API or approach. > Switching say from FOAF to Xesam is a matter of providing an ontology > description file, which none of concern for Soprano devs and other users of > the system. > > -- Evgeny > _______________________________________________ > Xesam mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xesam _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
