Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

• master

Tags

resources.mdwn

Here we’ll see how resources are used to describe real-world concepts and objects.

A resource is a reference to a thing we want to describe. Where do we begin? A natural way to begin a description may be to say “this thing exists” and then start saying things about it. But the expression model doesn’t need to require a statement like that. What determines the existence of a resource is the existence of statements mentioning it. If none exist, the resource doesn’t exist. If it is mentioned in any statement, doesn’t matter which, then it exists.

If we want to say anything about the resource, then its uid is already mentioned somewhere in some other statement. If nothing is said about the resource, then it is just a uid, just a sequence of bytes - it doesn’t mean anything. The mere existence of this reference to a thing is meaningless, because we know nothing about what exactly is referenced. It’s like saying “something exists”, which is obvious. Therefore, we skip straight to describing the thing.

Thus, any usage of a uid means a resource with that uid exists. However, it is probably a good idea to begin descriptions like in math: mention the “type” or the “class” of the thing, i.e. “what it is”, i.e. to which set it belongs. For example, “John is a person” is a good way to start talking about John. Then we can say more things about John, like “John loves Anne”.

The definition of existence implies how a resource can be removed from a database: All statements using it should be removed. Deleting the “John is a person” statement doesn’t delete the information about John. Actually, the statement “John loves Anne” may imply, through the domain of the loves property, that the object of the statement - John - is a person. In that case, removing the statement “John is a person” doesn’t remove any information from the database.

Assume we want to begin describing John, and we choose to start with “John is a person”. Since John is not described yet, he has no uid referring to him. So we must begin by generating a uid. After that, we just need to append the uids of the is-a property and the Person class, which already exist.

As mentioned in previous sections, a uid in machine’s database can be any sequence of characters. However, some aspects of uids must be examined: Should uids have any meaning? Should they refer to the location of the database describing John? Should they contain the strings “john” and “doe”?

A common format for unique identifiers used in several semantic web/desktop frameworks is the Unique Resource Identifier (URI), or its Unicode-enabled counterpart IRI (I for Internationalized). Every URI can be a URN (name) or a URL (locator) or both. A URN is just a string uniquely identifying the resource, while a URL is a pointer to the location of the object being referenced.

Examples:

• urn:isbn:0451450523 A book identified by its book number
• http://en.wikipedia.org/wiki/Uniform_resource_locator A page in Wikipedia identified by location

Unlike in conventions of other languages, like RDF, the expression model sees the inclusion of meaningful information in the uid as a design flaw. Example: In RDF, ontologies usually have URIs that point to a webpage containing the definition or specification of the ontology. Why? If I create a local copy of the same file, nothing makes that remote file special compared to my copy. Another example: Sometimes the URI of a description of a person points to the location of the file itself. Again, I can make a copy. What the URI means is the “source” of the data, from which all copies originate.

In the expression model here, this meaning of the URI is a flaw, because identifiers should not mean anything. Clearly a URI that points to a file allows you to paste it in the web browser’s address bar and download that file. However, it is not the meaning itself that creates the problem, but our uncontrolled ability to recognize meaning. In other words, if we could set our brain to ignore the meaning and treat a URI as a random sequence of characters, it would be as if it really was a random sequence. But since we cannot, and we do recognize patterns and meaning well, the key to removing any easily-visible meaning from a URI is not using any patterns intended for humans.

Note that even less-recognizable patterns such as UUIDs generated from the current time and date can be used to retrieve information, e.g. time and date of generation could be deduced from a UID. Thus the best “protection against meaning” is to use a (possibly pseudo) randomly generated identifier.

Here’s a practical example: Assume our semantic database contains the following statement:

file:///home/john/Music/article.odt is-a Document

The uid contains information: The location of the document. This is bad, because the location can easily change, while a uid is supposed to remain constant. Also, uids like this cannot be unique, because that file can be deleted or moved, and a new totally different file with the same location and name can take its place. The solution would have to be to change the uid of the first file (otherwise the uid of the new one won’t really point to it), and that could easily lead to problems is locations of two files are switched, etc.

Our universal solution is to remove all meaning from the uid. Assume we can go back in time and choose again how to insert this information into the database. First we generate a UUID to serve as a uid:

de1785195a75aa690c6c4fc252977b0f

Now we can use our convention to “declare” this new resource by stating where it belongs:

de1785195a75aa690c6c4fc252977b0f is-a Document

Now we can state where the document is stored:

de1785195a75aa690c6c4fc252977b0f is-stored-at “file:///home/john/Music/article.odt”

Now moving the file to another location does not change the unique identifier: Which makes sense semantically, since we still want to refer to exactly the same thing - that same document - and only the location has changed. Just like a person walking across a room remains the same person along the whole walking process (and probably after that too).

It is very important to note that properties have a restriction which other resources do not: For resources in general, any mentioning of the uid “creates” the resource. But for properties it’s different. If we used the uid of is-stored-at in the above example without first stating it is a property, one of the following problems would occur:

1. If the database assumes is-stored-at is a property, it could create a contradiction in case we used a non-property resource there by mistake.
2. If the database does not assume that, it cannot test the validity of the object and subject using the property’s domain and range.

If a specific database tests validity as mentioned (currently the expression model doesn’t require it), and the domain is not “Resource”, then it will reject the statement unless the object resource has alreay been declared to be a member of the corresponding set or a subset of it. In this case, we would have to use the begin-by-stating-where-belongs approach. A similar restriction applies to the range of the property.

As you can see, starting with “John is a person” is a good idea. It’s logical and prevents unwanted and unexpected results later when inserting more statements.