Uuuh sorry for the useless post, I got lost in this discussion broken across several threads...
Le Sat, 20 Nov 2010 21:09:13 +0200, Adrien Bustany <[email protected]> a écrit : > Hi all, > > on GNOME the standard semantic engine is called Tracker > (tracker-project.org). It also uses the Nepomuk ontologies, so it > should be easy to make things work the same in GNOME and KDE. Having a > common interface surely sounds like a good idea. The question is now > if we want a high level interface (ie. "add a tag") or a low level one > ("run sparql query")... > > Cheers > > Adrien > > Le Sat, 20 Nov 2010 02:06:51 +0000 (GMT), > Bruce Adams <[email protected]> a écrit : > > > > > Hi, > > If I may ask what is the other project? As it will obvious have > > bearings on where > > you want to focus your efforts. > > > > Brainstorming sounds like a good plan. Perhaps starting with a wide > > scope before narrowing down to what is in and out of scope > > and ultimately keeping it simple and acheivable. > > > > I'm new so apologies that this probably isn't. > > > > I'd like to start with resource discovery. > > Given a URI we need to know. > > what services provide meta data for it > > what kind of meta data each service provides (reference to an > > ontology?) > > > > Given a mounted disk semantic information could be provided by one > > or more of at least the following: > > a (e.g. nepomuk) server using a user specific database > > a local server using a shared database > > a remove server using a shared database > > a filesystem that permits embedded semantic information. > > > > Ideally I'd like to be able to do the same for a web-page which is > > why I said URI > > rather than file. Including web-pages would most likely imply using > > W3 standard methods for passing semantic information around. > > > > I'm not clear if or how nepomuk handles security issues relating to > > users sharing > > a database and controlling access and visibility of it. > > > > For each resource we need to know what priviledges we have. > > Most importantly is it read only. > > > > I'm primarily interested in tagging folksonomies. > > I'm sufficiently new that I don't know how (in)compatible the > > ontologies used by nepomuk are with those used elsewhere (OSCAF and > > Gnome). > > > > The paper http://tagont.googlecode.com/files/TagOntPaper.pdf > > suggests a common ontology. > > It includes the following suggested queries which look a lot like > > some of my tagging use cases. > > > > • get all taggers > > • get all tags used by a tagger X > > • get all resources which have been tagged more > > than once > > • get all tags for a resource A > > • get tags from users X,Y,Z for resource A > > > > > > Myself I would very much like an API that just provides this without > > having to writes SPARQL > > queries as that lowers the entry requirements for using it. > > > > Some more vague ramblings in the direction of a (C++) API before I > > head off to sleep. > > I had something like this in mind for a libtagger.so which it what > > started me searching for information > > and led me to nepomuk. > > > > Entity -> File or URL > > Service - description of a meta data provider > > Tag - includes a simple string name > > > > std::set<Service> Entity::listServiceProviders() > > > > std::set< Tag> Entity::listTags() > > std::set< Tag> Entity::listTags(<semantic info provider or list > > there>) std::set< Tag> Entity::listTags(<some kind of filter>) > > > > <some kind of status, or just exceptions when it goes wrong> > > Entity::addTag(tag) > > > > methods to convert a tag to and from a string > > simply Tag::Tag(std::string) - > > std::string Tag::toString() > > > > perhaps this is only sensible in the context of a given service > > provider? > > > > Service::listDefinedTags(); > > > > Entity::addTag(service, tag, bool createTag) > > > > I have to say some of this bears a resemblance to the existing > > nepomuk API but simplified with not an ontology in sight (though its > > there under the hood). > > > > Meta-data aware file ops. > > > > CopyFile - copy file & meta-data > > MoveFile - move file & meta-data > > > > The following would apply to URLs as well: > > > > CopyMetaData( file1, file2) - overwrite the meta data for file2 > > with that for file1 > > CopyMetaData( file, provider1, provider2) - copy the meta data one > > provide has for a file to another provider > > ExportMetaData(file); - to file or a (opaque?) meta data object > > ImportMetaData(file); > > > > These would need to be clever enough to decide what to do based on > > the resource providers for the start and end points. > > > > I was thinking about cobbling this kind of API together for my next > > project. > > > > I also wonder about having a backup file-system based metadata > > database along the lines of > > > > <dir> > > <file to tag> > > ,metadata/ > > tags/ > > <file to tag> <- contains tags as RDF, XML or a list > > of strings one per line. > > > > Regards, > > > > Bruce. > > > > > > ----- Original Message ---- > > > From: Sebastian Trüg <[email protected]> > > > To: Bruce Adams <[email protected]> > > > Cc: [email protected] > > > Sent: Wed, November 17, 2010 2:18:30 PM > > > Subject: Re: [Nepomuk] Re: nepomuk & gnome & firefox > > > > > > Actually I have planned to start on that API mid of next week > > > since I need it for another project. Maybe a good idea to start > > > would be to brainstorm on the necessary method the API would > > > require, ie. come up with a bunch of use cases. > > > > > > We could put that on techbase.kde.org... > > > > > > Cheers, > > > Sebastian > > > > > > On 11/17/2010 02:24 PM, Bruce Adams wrote: > > > > > > > > That's pretty much exactly what I'm looking for. > > > > So I'm happy to collaborate on any efforts to get something > > > > like that > > going. > > > > > > > > > > > > Regards, > > > > > > > > Bruce. > > > > > > > > > > > > ----- Original Message ---- > > > >> From: Sebastian Trüg <[email protected]> > > > >> To: [email protected] > > > >> Sent: Wed, November 17, 2010 1:04:19 PM > > > >> Subject: [Nepomuk] Re: nepomuk & gnome & firefox > > > >> > > > >> This is what I mean: a DBUs API that provides what the > > > >> Nepomuk-KDE API provides at the moment. > > > >> > > > >> Cheers, > > > >> Sebastian > > > >> > > > >> On 11/17/2010 09:58 AM, Bruce Adams wrote: > > > >>> ----- Original Message ---- > > > >>> > > > >>>> From: Richard Dale <[email protected]> > > > >>>> To: [email protected] > > > >>>> Sent: Tue, November 16, 2010 5:40:17 PM > > > >>>> Subject: [Nepomuk] Re: nepomuk & gnome & firefox > > > >>>> > > > >>>> On Wed, Nov 10, 2010 at 7:11 AM, Sebastian Trüg > > > >>>> <[email protected]> > > wrote: > > > >>>>> The solution is simply what I said: we support the tracker > > > >>>>> API and that's it. The other way around is not possible > > > >>>>> anyway. > > > >>>> OK, how would you like to support the tracker API? I'm > > > >>>> still not > > clear > > > >>>> on what you are saying. > > > >>>> > > > >>>> One way would be to write a Tracker backend for Soprano 2.x > > > >>>> which would support a subset of the Virtuoso backend's > > > >>>> functionality. > > > >>>> > > > >>>> Another way would be to write a QSparql based backend for > > > >>>> Soprano 2.x which would interface with Tracker, and also > > > >>>> support SPARQL endpoints and Virtuoso as a side effect, > > > >>>> although you would be perfectly > > welcome > > > >>>> not to use that extra functionality as the drivers are only > > > >>>> plugins. I happen to be an expert on the Tracker apis (both > > > >>>> the DBus one and the newer 'direct api'), and the Tracker > > > >>>> team are cooperating to improve their api WRT its use in > > > >>>> QSparql. I am also an active KDE developer who has > > > >>>> developed language bindings for Soprano and Nepomuk, and I > > > >>>> am quite happy to work on KDE things in my spare time. So > > > >>>> if anyone can do this particular task I feel I should be > > > >>>> about the person person to try. > > > >>>> > > > >>>> I don't know what your plans for Soprano 3.x are as I > > > >>>> haven't studied the code yet. > > > >>>> > > > >>>> -- Richard > > > >>> > > > >>> > > > >>> From my angle as a noob a lot of this is missing the point. > > > >>> I want to read and write tag clouds in a platform > > > >>> independent way. A rich ontology is all very well (and > > > >>> vitally important for more advanced > > > > > > >> uses). > > > >>> But at the start of the day I want to be able to do > > > >>> something like: > > > >>> > > > >>> Nepomuk::File file( "some/path"); > > > >>> file.addTag("foo"); > > > >>> > > > >>> Just like in the examples here: > > > >>> > > > >>> > > > >>> http://api.kde.org/4.x-api/kdelibs-apidocs/nepomuk/html/examples.html > > > >>> > > > >>> and see the tag "foo" appear in the "quickview" in dolphin > > > >>> and the equivalent Gnome apps (and firefox). > > > >>> > > > >>> Surprisingly this is 'bleeding edge' stuff (kde 4.6) rather > > > >>> than the bare > > > > > > >>> essentials > > > >>> and doesn't work on my up to date ubuntu 10.10 installation > > > >>> which is > > >still > > > > > > >> on > > > >> > > > >>> kde 4.5.1. > > > >>> (actually this is beyond the bleeding edge as the tag needs > > > >>> to be > > >declared > > > > > > >>> first, but you get the idea) > > > >>> > > > >>> Regards, > > > >>> > > > >>> Bruce. > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> Nepomuk mailing list > > > >>> [email protected] > > > >>> https://mail.kde.org/mailman/listinfo/nepomuk > > > >>> > > > >> _______________________________________________ > > > >> Nepomuk mailing list > > > >> [email protected] > > > >> https://mail.kde.org/mailman/listinfo/nepomuk > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Nepomuk mailing list > > [email protected] > > https://mail.kde.org/mailman/listinfo/nepomuk > > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
