[Nepomuk] Nepomuk Core - Questions & Patches

[Sebastian Trüg]

On 05/31/2010 01:44 PM, Vishesh Handa wrote:
> Resources are identified by one of these 3 ways -
> 1. nao:identifier
> 2. nie:url (includes the whole filex:/ part)
> 3. nepomuk:/res/
> 
> m_kickOffId uses 1, 2 (minus the filex:/) & 3. And m_kickOffUri uses 2 &
> 3. I say, we scrap the m_kickOffId, and store the nao:identifier in the
> m_kickOffUri ( perhaps name it to something else? )
> 
> The determineUri code would become a lot simpler -
> 
> if( m_kickOffUri.isValid() ) {
>    // Either 2 or 3
> }
> else {
>    // nao:identifier
> }
> 
> The would even clear one of the odd cases where someone tries to
> initialize a Resource by providing its nepomuk:/res/ uri as a QString
> instead a QUrl.

So you want to store a string in a KUrl then? Well, that could work indeed.


>     > 2. Convert the ResourceData m_kickOffUri into a list AND make sure
>     that
>     > while determining one URI it adds all other cases to the lists as
>     well.
>     >
>     > Number 1 is more of a convenience, but *2* is really important. You've
>     > done half the job ( I thought we'll take care of it in another patch )
>     >
>     > Now, about the comments in determineFinalResourceData(). The flaw with
>     > our, not so little, proxy removal plan was that if -
>     > Resource r1("foo");
>     > r1.determineUri()
>     >
>     > Resource r2( foo's nie:url );
>     > r2.determineUri() // The proxy thing would be activated ( could be
>     > avoided via 2 )
>     >
>     > Resource r3( foo's nie:url );
>     > r3.determineUri() // The proxy thing is AGAIN activated as the nie:url
>     > wasn't added to the list.
>     >
>     > With your patch you seem to have fixed the problem. But I would have
>     > preferred the more concrete solution via 2.
> 
>     Agreed.
> 
> How about converting them into hash tables instead of lists? That way we
> could easily check if addProperty() or removeProperty() updates any of
> the identifying properties in m_kickOddUri. We could then even
> potentially stop clearing up the cache after ever metadata move
> operation.  

What would the hash contain?

Cheers,
Sebastian