Projects/Nepomuk/Uris: Difference between revisions
(Marked this version for translation) |
(Removed page from translation) |
||
Line 1: | Line 1: | ||
== Scope of this page == | == Scope of this page == | ||
This document describes in depth how URIs are stored in '''Nepomuk''', and their significance. | This document describes in depth how URIs are stored in '''Nepomuk''', and their significance. | ||
== What is a URI? == | == 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 - | 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 | * URN - Uniform Resources Names | ||
* URL - Uniform Resource Locator. | * 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 - <tt>urn:isbn:037584614X</tt>. 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 [http://www.amazon.com/Nick-Norahs-Infinite-Playlist-Rachel/dp/037584614X the book] | 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 - <tt>urn:isbn:037584614X</tt>. 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 [http://www.amazon.com/Nick-Norahs-Infinite-Playlist-Rachel/dp/037584614X the book] | ||
A URL, in contrast, provides a way to access the resource. For example - <tt>file:///home/user/file</tt>. This url clearly dictates that the <tt>file</tt> protocol should be used along with the path <tt>/home/user/file</tt>. It does not give a unique way of identifying the resource. It just provides one way to access the resource. | A URL, in contrast, provides a way to access the resource. For example - <tt>file:///home/user/file</tt>. This url clearly dictates that the <tt>file</tt> protocol should be used along with the path <tt>/home/user/file</tt>. 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? == | == 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 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 - | ||
<blockquote>nepomuk:/res/uuid</blockquote> | <blockquote>nepomuk:/res/uuid</blockquote> | ||
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. | 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? == | == 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 [http://oscaf.sourceforge.net/nie.html#nie:url <code>nie:url</code>]. | 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 [http://oscaf.sourceforge.net/nie.html#nie:url <code>nie:url</code>]. | ||
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. | 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 == | == 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 <tt>smb:/192.168.1.50/Multimedia/</tt> or <tt>akonadi:?item=21</tt>. These all are stored in the nie:url property of the resource. | A URL is like the physical representation of an object. In '''Nepomuk''' all URLs must have a proper scheme that KDE supports. Example <tt>smb:/192.168.1.50/Multimedia/</tt> or <tt>akonadi:?item=21</tt>. These all are stored in the nie:url property of the resource. | ||
== You're lying! I see resource URIs like <tt>akonadi:?item=21</tt> == | == You're lying! I see resource URIs like <tt>akonadi:?item=21</tt> == | ||
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. | 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? == | == 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 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. | The second reason is that all URIs follow one naming convention. | ||
== What about the Semantic Web? == | == 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. | '''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. | ||
[[Category:Documentation]] | [[Category:Documentation]] | ||
[[Category:Development]] | [[Category:Development]] | ||
[[Category:Tutorials]] | [[Category:Tutorials]] | ||
Latest revision as of 12:33, 9 February 2018
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.