XMP, Krita, KFileMetaInfo and Strigi

[Evgeny Egorochkin]

On Saturday 23 June 2007 22:46:06 Richard Dale wrote:
> On Saturday 23 June 2007, Evgeny Egorochkin wrote:
> > On Saturday 23 June 2007 20:08:50 Cyrille Berger wrote:
> > > > That is why I thought Nepomuk could not
> > > > solve the problem right away. What would be of interest however,
> > > > would be to also store the data in Nepomuk to make it searchable and
> > > > linkable. maybe for this we need a bridging ontology that links XMP
> > > > data with data specified in Nepomuk ontologies.
> > >
> > > Yes but that's really for the future :)
> >
> > Not so distant. Many of XMP features can be mapped to existing Nepomuk
> > ontology, and I'll consider missing XMP features when coming up with
> > suggestions for the next Nepomuk ontology draft.
> >
> > The problem is that you can't do 1:1 nepo-xmp mapping :(
>
> Does that mean that Nepomuk has it's own ontology, and we can't use
> existing RDF ones?

Reusing existing ontologies is not as straightforward as you might think. The 
devil is in the details. 

The problem is that some ontology might have a Name property for person. Other 
ontology has FirstName and LastName properties.

One ontology might express rating as an integer in 0-100 range, other one uses 
float in 0-1 range etc.

When ontologies use essentially different structures/ideologies to represent 
data, it becomes a real headache.

Often you have several ontologies trying to represent the same data( a good 
deal of media ontologies is an example of this).

This is further complicated by outdated ontologies, ontologies with 
questionable practices(I had pointed out some issues with XMP which go 
against todays semantics approaches, but it was ok when the standard was 
drafted)

Thus, making an ontology as generic as nepomuk is intended to be involves 
compromises.

Also, if it becomes clear you can't be compatible in some aspect with all 
existing ontologies, it makes sense to adopt the most sensible approach  
according to todays knowledge, and not yesterdays assumptions or outright 
mistakes.

That said, proper ontology design and a reasonable coding effort can map 
90-95% of other ontologies features even in cases of complex and troublesome 
ontologies.

Compare this to typical usage cases like IDv2.4. Hardly anyone uses even 10 of 
tags provided by the standard, where in fact there are 10x more.

The concern of 100% 1:1 mapping is for certain production apps that must have 
access to all obscure features of a particular standard.

> Is it ok to read from the Redland triple store directly or should it always
> be done via a Nepomuk service? I ask because Ruby has some nice software
> for reading and writing to rdf stores (ActiveRDF), and I would like to be
> able to use those apis for kde/ruby programming. QtRuby/Korundum can use
> QtDBus too. Should C++ programs access Nepumuk via Soprano (or ActiveRDF
> for ruby), and hence the triple store directly, or only go via a dbus api?

While at this moment it might not matter, eventually you may expect some 
performance tweaks and data stored quite differently than presented via 
KMetaData API. Also, I think in many cases native constructs of OO languages 
are much easier to use as compared to raw RDF.

Still, Sebastian is in a better position to answer this question.

-- Evgeny