< Projects | Nepomuk | Uris Contents 1 Scope of this page 2 What is a URI? 3 So what does Nepomuk use? 4 Doesn't Nepomuk need the location of the Resource? 5 Tell me more about these URLS 6 You're lying! I see resource URIs like akonadi:?item=21 7 Why go through all this trouble? 8 What about the Semantic Web? Scope of this page This document describes in depth how URIs are stored in Nepomuk, and their significance. What is a URI? 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 - URN - Uniform Resources Names URL - Uniform Resource Locator. A URN is a unique way of identifying a resource. It does not provide any information about how the resource can be found> Rather it provides a way to uniquely identify a resource. For example - urn:isbn:037584614X. This urn tells you nothing about how to find the book that it just mentions a unique identifier. You can take the ISBN and somehow locate the book A URL, in contrast, provides a way to access the resource. For 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. So what does Nepomuk use? 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 - nepomuk:/res/uuid 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. Doesn't Nepomuk need the location of the Resource? Yes, we do! But 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 resources have a location. Nepomuk is also 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. Tell me more about these URLS 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. You're lying! I see resource URIs like akonadi:?item=21 This URI nomenclature was decided in June 2011. We're still in the process of making sure all URIs follow our naming convention. With KDE 4.10, there will be a data migration client which will make sure the old data is converted to this new uri format. Why go through all this trouble? 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. What about the Semantic Web? Nepomuk is the Semantic Desktop, while we acknowledge the existence 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 come talk to us. Retrieved from "https://techbase.kde.org/index.php?title=Projects/Nepomuk/Uris/en&oldid=77193" Categories: DocumentationDevelopmentTutorials This page was last edited on 10 December 2012, at 17:43. Content is available under Creative Commons License SA 4.0 unless otherwise noted.