This document describes in depth how URIs are stored in Nepomuk, and their significance.
A URI or Uniform Resource Identifier is a string of characters used to identify or locate a resource. URIs can be of two types, or both - URNs and URLs. A URN, Uniform Resource Name, is a unique way of identifying a resource. It does not provide any information about how the resource can be found, example - urn:isbn:0374193681. A URL, Uniform Resource Locator, provides a way to access the resource. Example - file:///home/user/file. This url clearly dictates that the 'file' protocol should be used along with the path '/home/user/file'. It does not give a unique way of identifying the resource. It just provides one way to access the resource.
Nepomuk URIs are in a way URNs, though unlike conventional URNs which provide a globally unique way of identifying a resource, they provide a unique way of identifying a resource on one machine. This is important - Nepomuk URIs are NOT machine independent. The same resource can have different URIs on different systems. This is because all URIs in Nepomuk are randomly generated. They follow a pattern -
where TYPE is either *res* or *ctx*. UUID stands for a Universally Unique Identifier. In Nepomuk this UUID is guaranteed to be unique on one system. A resource with the same UUID can exist as completely different resources on different systems.
Yes, we do! But just like "A rose by any other name would smell as sweet", the location of a resource is independent of its name. Its name ( UUID ) never changes. If the resource has a location then the location is stored as a URL using the property nie:url.
Not all resource have a location. Nepomuk is used to store abstract stuff like Contacts, Events and People, they do not have a location. Concrete stuff like pictures, videos and files do have locations.
A URL is like the physical representation of an object. In Nepomuk all URLs must have a proper scheme that KDE supports. Example `smb:/192.168.1.50/Multimedia/` or akonadi:?item=21. These all are stored in the nie:url property of the resource.
This URI nomenclature was decided in June 2011. We're still in the process of making sure all URIs follow our naming convention. Hopefully we can automate this process.
The rationale in having random UUID based URIs in Nepomuk is two fold. One, we have a guarantee that the URI is random, and means nothing. This is important when restoring backups or synchronization or when sharing resource among different systems. If you're restoring a resource and its URI already exists, no problem, just generate another one. It's not like they have any concrete meaning. The URL however does have a concrete meaning, and that we need to respect.
The second reason is that all URIs follow one naming convention? ( vHanda: What was the second reason? )
Nepomuk is the Semantic Desktop, while we acknowledge the fact of the Semantic Web, we currently do not go out of our way to support it. It's a messy situation, and we don't have a solution right now. If you have any ideas on how we can have better interoperability with the Semantic Web, then please let us on the Nepomuk Mailing List.