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
