[Nepomuk] Re: Akonadi::Nepomukfeeder: why aren't we using NIE::DataObjects / DataSources?

[Christian Mollekopf]

On Tuesday 22 February 2011 11:43:31 Sebastian Trüg wrote:
> I am not exactly sure what you mean here. Keep in mind that both
> nie:DataObject and nie:DataSource are RDF classes and not C++ classes.
> This means they are used to describe resource in the Nepomuk DB, not to
> implement some C++ concept.

Yes, but as I understand it, the idea would be to have a service, which is 
controlled from the nepomuk side, which has read/write access to akonadi.
This service is the represented in the Nepomuk DB by the nie:DataSource.

This nie:Datasource creates nie:DataObjects, which is the representation of 
resources for plain akonadi items. Those items are then interpreted as 
Todo/Task etc.

The way we are currently doing it, akonadi just writes data to nepomuk, but 
nepomuk does not write back to akonadi and therefore it is not possible to 
abstract akonadi away with nepomuk by applications (since they have to write 
to akonadi directly).

Further the akonadiItem itself is nowhere represented, but only directly the 
interpretation as i.e. ncal:Todo, and this interpretation is coupled to the 
physical storage location (it is identified by the akonadi id). If it was 
implemented with the nie:DataObject the Todo would be decoupled from a specific 
akonadi item, as the item itself would be represented by the nie:DataObject.

This would also allow that an item changes the storagelocation from akonadi to 
a file, without changing the nie:InformationElement (except setting a new 
nie:DataObject)

In pratice I don't know where this exactly would bring an advantage, as I'm 
not sure if it is even allowed that an akonadi item changes the type, or why 
we should recreate an item representing the same nie:InformationElement.
It would however allow for more flexibility in the future and follows the spec 
more closely by decoupling physical representation from interpretation.

Summary:
-nie:DataSource so akonadi is completely wrapped by nepomuk
-nie:DataObject to decouple physical storage from Interpretation

Cheers,

Chris

> 
> Cheers,
> Sebastian
> 
> On 02/19/2011 12:45 PM, Christian Mollekopf wrote:
> > Hi,
> > 
> > Instead of the NepomukfeederAgents, shouldn't we actually use  an
> > AkonadiObject which is a subclass of NIE:DataObject together with a
> > NIE:DataSource for akonadi?
> > 
> > I couldn't find much info on the topic, nor any code of such a DataSource
> > / DataObject, but with the Nepomukfeeder we seem to have ignored the
> > DataObject side of NIE completely.
> > Also this works only one way (Akonadi -> Nepomk) while the other approach
> > would work both ways if I understood correctly.
> > 
> > I reckon with the akonadi DataObject/DataSource part implemented
> > correctly, one could ignore akonadi completely in nepomuk applications,
> > since Nepomuk would encapsulate it, while akonadi i.e. still can sync
> > the items over the internet in the background, right?
> > 
> > I understand that it was probably easier to go the Nepomukfeeder way as a
> > first implementation, but the proper thing to do would be IMHO the other
> > way.
> > 
> > Might be interesting thing to keep in mind for future implementations.
> > 
> > But maybe I just misunderstood the the whole thing ;-)
> > Anyone some Ideas on this?
> > 
> > See: http://www.semanticdesktop.org/ontologies/nie/ for reference
> > 
> > Cheers,
> > 
> > Chris
> > 
> > 
> > _______________________________________________
> > Nepomuk mailing list
> > Nepomuk at kde.org
> > https://mail.kde.org/mailman/listinfo/nepomuk
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk