Add new comment Your name. More information about text formats. Web page addresses and e-mail addresses turn into links automatically. Lines and paragraphs break automatically.
Now we can re-write the statements in List 2. After replacing the simple names we have used in List 2. The answer is yes, and it is indeed very important to do so. Let us discuss this more in the next section. With this said, we can change rule 2 to make it more complete: Rule 2: The name of a resource must be global and should be identified by Uniform Resource Identifier URI.
The name of predicate must also be global and should be identified by URI as well. The first reason is similar to the reason why we should use URIs to name subjects and objects. For example, one group of reviewers who reviews cameras may use string model to indicate the fact that Nikon D has D as its model number, and another group of reviewers who mainly review television sets could also have used model to mean the specific model number of a given TV set.
A given application that sees these model strings will have difficulty in distinguishing their meanings. Another benefit of using URIs to name predicates comes from the fact that this will enable the predicates to be treated as resources as well. This in fact has a far-reaching effect down the road. This means that additional information about the given predicate can be added. As we will see in later chapters, by adding this additional information, we can specify some useful fact about this predicate. For example, we can add the fact that this given predicate is the same as another predicate, or it is a sub-predicate of another predicate, or it is an inverse predicate of another predicate, and so on.
This additional information turns out to be one of the main factors responsible for the reasoning power provided by RDF models, as you will see in later chapters. The third benefit that will also become more obvious later is the fact that using URIs to name subjects, predicates, and objects in RDF statements promotes the development and use of shared vocabularies on the Web.
In other words, by discovering and using vocabularies already used by others to describe resources implies a shared understanding of those concepts, and that will eventually make the Web much more machine friendly. Again, we will discuss this more in the chapters yet to come.
Now, with all these said, let us name our predicates as shown in List 2. So far at this point, we have covered two basic rules about the abstract RDF model. Before we move on to other aspects of the abstract model, we would like to present a small example to show you the fact that these two rules have already taken you farther than you might have realized. With the statements listed in List 2.
The pseudo-code in List 2. In fact, try out some other questions, such as who is the manufacturer of Nikon D and what model number does it have. You will see the code does not have 2. And clearly, based on the knowledge presented in the RDF statements Table 2.
It is also not hard for us to imagine some more interesting examples if we can add more RDF statements with more complex predicates and objects. In this section, we will describe two important components of abstract model: RDF literals and blank node.
- Holdings: A Developer's Guide to the Semantic Web;
- A Developer’s Guide to the Semantic Web.pdf - Liyang Yu A....
- Skinny Bitching: A thirty-something woman mouths off about age angst, pregnancy pressure, and the dieting battles youll never win.
- A developer's guide to the semantic web!
- Cruising World (Novemer 2006)?
- Beginning VB 2005 Databases: From Novice to Professional.
- Multiple Imputation and its Application;
And first, let us summarize all the terminologies we have learned so far. To make our learning easier, let us summarize these terminologies and their synonyms in this section. So far, we have learned the following: subject: object: predicate: used to denote resource in the world, must be identified by URI, and also called node or start node in an RDF graph; used to denote resource in the world, must be identified by URI, and also called node or end node in an RDF graph; used to denote the relation between subject and object, must be identified by URI, also called edge in an RDF graph.
This summary needs to grow for sure. Also, the string value has nothing to do with URIs. Now, besides understanding predicate as a relation between the subject and object resource, we can also perceive it as putting some constraint on one of the attributes properties of the subject resource. If a resource is used as its value, this resource may or may not be identified by a URI.
If it is not represented by a URI, it is called a blank node. Note that the object in one statement can become the subject in another statement such as myCamera:PictureQuality, for example. Therefore, a blank node object in one statement can become a blank node subject in another statement.
To summarize what we have learned: subject: object: can be URI named resource, or a blank node; also called property value, can be URI named resource, literal or blank node; predicate: also called property, must be URI named resource. Let us move on to learn more about literals and blank nodes; they are all important concepts in abstract RDF model. As we have seen in List 2. A literal value can be optionally localized by attaching a language tag, indicating in which language the raw text is written, for example, "Dr.
A literal value can also be optionally typed by using a URI that indicates a datatype, and this datatype information can be used by RDF document parser to understand how to interpret the raw text. To add a datatype to a literal value, put the literal value in quotes and then use two carets, followed by the datatype URI. Lines 2 and 3 are also un-typed literal values, but they do have language tags. Line 4 is a typed literal value, and its full datatype URI is also written out. Note that an un-typed literal, regardless of whether it has a language tag or not, is completely different from a typed literal.
Therefore, the literal value on line 1 and the literal value on line 4 are considered two different things and have nothing related to each other at all. In fact, all the four literal values in List 2. It is therefore possible that two typed literals that appear different can be mapped to the same value. For example, the two statements in List 2.
But before we move on, here is one more thing to remember: literals are only used as object values; they can never be used as subjects. It in fact happens quite often in RDF models and is also called an anonymous node or a bnode. And obviously, the blank node here represents this specific resource. Note that when we say a node is a blank node, we refer to the fact that it does not have a URI as its name.
However, in real RDF documents, it will most likely be assigned a local identifier so that it could be referred within the same document scope. For example, Fig. Now, if we add the statements in List 2. As you can tell, the local name of the blank node is not included in the graph, and it is now a real blank node — probably that is why the name was created in the first place.
The main benefit of using blank nodes is the fact that blank node provides a way to model the so-called n-ary n-way relationship in RDF models. To see this, first understand that RDF only models binary relationships. Now, there could be another reviewer who has the same name. In order to eliminate this ambiguity, we decide that we will add more details to the reviewer. This time, not only will we spell out the first name and the last name as in List 2.
However, by doing so, the camera is no longer related to a single literal string; instead, it is related to a collection of components a last name, a first name, and an e-mail address. So how does RDF model this n-way relationship? The solution is to create another resource to represent this collection of components, and the original subject keeps its binary relationship to this newly created resource.
Meanwhile, each one of the components in this collection can become a separate property of the new resource, as shown in List 2. The important fact is that we have now successfully modeled a three-way relationship between a given camera and its reviewer. As you can easily imagine, there will be lots of similar scenarios like this in the real world, where we will have to model n-ary relationships. However, most of these new URIs will never be referred from outside the graph; it is therefore not necessary for them to have URIs at all.
This is exactly the concept of blank node, and this is how blank node can help us to model a given n-ary relationship. Again, as we have mentioned, most RDF processors will automatically assign a local node identifier to a blank node, which is needed when the RDF statements are written out. In addition, other statements within the same document can make reference to this blank node if necessary. Of course, a blank node is not accessible from outside the graph, and it will not be considered when data aggregation is performed.
Before we move on, here is one more thing to remember: blank nodes can only be used as subjects or objects; they cannot be used as properties. A statement is also called a triple. Therefore, the subject and object of a given statement are also called nodes, and its predicate is also called edge. Predicates denote the relationship between subjects and objects.
Therefore, a statement also has the form resource, property, propertyValue. For a given resource or property, if there is an existing URI to name it, you should reuse it instead of inventing your own. To model an n-ary relationship, intermediate resources are introduced and blank nodes are quite often used. If a literal is used as its value, the literal can be typed or un-typed, and it can also have an optional language tag.
Otherwise, review the material here in this section, and make sure you understand it completely. The next step is to define some serialization syntax for creating and reading concrete RDF models, so applications can start to write and share RDF documents. Note that this is not the only serialization syntax that is being used. This prefix will often become the namespace prefix for this vocabulary, and the URIs in this vocabulary will be formed by appending individual local names to the end of this common leading string.
For this reason, this vocabulary is also referred to as the rdf: vocabulary. The terms in rdf: vocabulary are listed in List 2. Line 2 also includes an XML namespace declaration by using an xmlns attribute, which specifies that prefix rdf: is used to represent the RDF namespace URI reference, i. Based on the discussion in Sect. Any term that has the name myCamera:name is therefore a term taken from this namespace. Now, any statement in a given RDF model is a description of a resource in the real world, with the resource being the subject of the statement.
It indicates the start of a description of a resource, and it uses the rdf:about attribute to specify the resource that is being described, as shown in line 4. In this example, it represents a subject of a statement. You can understand line 4 as the following: Now, given the fact that tag rdf:Description indicates the start of a statement, must signify the end of a statement.
Indeed, line 6 shows the end of our statement. With this being said, line 5 has to specify the property and property value of the statement. Since the property value in this case is another resource, rdf:resource is used to identify it by referring its URI. Note that line 5 is nested within the rdf:Description element; therefore, the property and property value specified by line 5 apply to the resource specified by the rdf:about attribute of the rdf:Description element. Clearly, each property XML node represents a single statement. Note that a given property node is always contained within a resource XML node, which represents the subject of the statement.
We will keep adding statements into this document until we have covered all the RDF vocabulary features. It is not hard to imagine that this kind of requirement is quite common in other applications as well. For example, we will want to express the fact that a certain resource is a person, another resource is a book, so on and so forth.
It then seems reasonable for RDF vocabulary to provide some term just for this purpose, so a given application does not have to invent its own. In RDF vocabulary, rdf:type exists to identify the type of a given resource. The subject node in Fig. Assigning a type to a resource has far-reaching implication than you might have realized now.
In fact, once we have the term rdf:type at our disposal, we can often write the statement in List 2. In fact, most RDF parsers will change List 2. In addition, some developers do believe the format in List 2. Now, let us take the rest of the statements from List 2. With the understanding of the first statement lines 5—7 , this new statement does not require too much explanation. However, we can make this a little bit more concise: since the two statements have the same subject, they can be combined together, as shown in List 2.
The two statements in the current RDF document lines 6 and 7, List 2. However, there is a little bit more about this myCamera:PictureQuality resource: it itself has a property that needs to be described, as shown by the last statement in List 2. This object resource is further described separately by using a new rdf:Description node at the top level of the document lines 11— Another way to represent resource as property value is to simply put the description of the object resource into the property XML node that uses this resource as the object value, as shown in List 2.
In fact, this pattern can be used recursively until all the resources have been described. Again, this is not new. We have learned how to use a literal value as the object of a property XML node line 10, List 2. Specially, the value is simply put inside the XML element. At this point, List 2. For example, line 14 tells us property myCamera:weight has a literal value of 0. However, given the fact that the Web is such a global resource itself, it might not be a good idea to use a literal value such as 0. When we do this, we in fact assume that anyone who accesses this property will be able to understand 50 2 The Building Block for the Semantic Web: RDF the unit that is being used, which may not be a safe assumption to make.
A better or safer solution is to explicitly express the value and the unit in separate property values. In other words, the value of myCamera:weight property would need to have two components: the literal for the decimal value and an indication of the unit of measurement kg. Note in this situation that the decimal value itself can be viewed as the main value of myCamera:weight property, whilst the unit component exists just to provide additional contextual information that qualifies the main value.
To implement this solution, we need to model such a qualified property as new structured value. More specifically, a totally separate resource should be used to represent this structured value as a whole. This new resource should have properties representing the individual components of the structured value. In our example, it should have two properties: one for the decimal value, the other for the unit.
This new resource will then be used as the object value of the original statement. RDF vocabulary provides a pre-defined rdf:value property just for this use case. This resource, as we discussed earlier, has two properties. The first property is the pre-defined rdf:value property; its value is 0. The other one is the uom:units property defined in the uom namespace line 3. Another interesting part of List 2.
Note that in line 16, tag does not have anything like rdf:about attribute. Therefore, this resource is an anonymous resource we have discussed the concept of anonymous resource in Sect. Why is the resource used by myCamera:weight property made to be anonymous? Since its purpose is to provide a context for the other two properties to exist, and other RDF documents will have no need to use or add any new details to this resource, there is simply no need to give this resource an identifier. In RDF models, there is an easier way to implicitly create a blank node. It is considered to be a shorthand method provided by RDF.
It indicates to the RDF parser that the contents of the myCamera:weight element lines 16 and 17 should be interpreted as the description of a new resource a blank node and should be treated as the value of property myCamera:weight. Without seeing a nested rdf:Description tag, the RDF parser creates a blank node as the value of the myCamera:weight property and then uses the enclosed two elements as the properties of that blank node.
Obviously, this is exactly what we wish the parser to accomplish. Let us take a look at typed literals in this section. Line 16 of List 2. Here, 0. However, sometimes, it is important for the RDF parser or the application to know how to explain the plain value. The solution is to use the rdf:datatype keyword from RDF vocabulary. It instead borrows an external datatype system, and currently, it is the XML Schema datatypes.
The reason is also very simple: since XML enjoys such a great success, its schema datatypes would most likely be interoperable among different software agents. Now let us use rdf:datatype to clearly indicate that the value 0. The result is the value of the rdf:value property, namely, 0. Note that there is no absolute need to use rdf:value in the above example. A user-defined property name can be used instead of rdf:value and the rdf:datatype attribute can still be used together with that user-defined property.
Line 14 shows one example: it specifies literal D should be interpreted as a string. In fact, RDF does not associate any special meaning with rdf:value; it is simply provided as a convenience for use in the cases as described by our example. However, this makes the line quite long and might hurt readability in some cases. More specifically, an XML entity can associate a name with a string of characters and this name can be referenced anywhere in the XML document.
A Developer's Guide to the Semantic Web by Liyang Yu
When XML processors reach such a name, they will replace the name with the character string which normally represents the real content. Since we can make the name really short, this provides us with the ability to abbreviate the long URI. Using this abbreviation, we have the following more readable version as shown in List 2. For example, in List 2. As you can see, that blank node is embedded inside the XML property node, myCamera:weight, and is used as the property value of this node.
This kind of embedded blank node works well most of the time, but it does have one disadvantage: it cannot be referenced from any other part of the same document. In some cases, we do have the need to make reference to a blank node within the same document. The idea is to assign a blank node identifier to a given blank node, so it can be referenced within this particular RDF document and still remains unknown outside the scope of the document.
More specifically, a statement using a blank node as its subject value should use an rdf:Description element together with an rdf:nodeID attribute instead of an rdf:about or rdf:ID discussed in later section attribute. By the same token, a statement using a blank node as its object should also use a property element with an rdf:nodeID attribute instead of an rdf:Resource attribute. We, on purpose, name this identifier to be youNameThisNode, just to show you the fact that you can name this node whatever you want to. The real benefit is that this resource now has a local identifier, so it can be referenced from other places within the same document.
Blank node is very useful in RDF, and we will see more examples of using blank node in later sections. In addition, note that rdf:nodeID is case sensitive. For example, an RDF parser will flag an error if you have mistakenly written it as rdf:nodeId. In fact, every single term in RDF vocabulary is case sensitive, so make sure they are right. In this section, we will discuss the things you can do to make it shorter. For example, compare List 2. In List 2. More specifically, List 2. On the other hand, List 2. Most RDF parsers will translate the abbreviated form into the long form first before any processing is done.
This does make the statement shorter; at least there is no long URI needed for the resource. However, to use rdf:ID, we have to be very careful. This seems to be contradicting to the very meaning of URI: it is the unique and global identifier of a resource, and how can it change based on the location of some file then? The solution is to explicitly state the in-scope base URI. Specifically, we can add the xml:base attribute in the RDF document to control which base is used to resolve the rdf:ID value.
As a summary, Lists 2. However, it might be a good idea to use rdf:about instead of rdf:ID, since it provides an absolute URI for the resource. Also, that URI is taken verbatim as the subject, which certainly avoids all the potential confusions. In this section, we will take a brief look at these capabilities. How do we express this fact in RDF? A container is a resource that contains things, and each one of these things is called a member in the container.
A member can be represented by either a resource or a literal. In this case, the resource represents a group of resources or literals, the order of these members is not significant, and there could be duplicated members as well. For example, the review criteria presented above can be modeled by using rdf:Bag. An rdf:Seq type resource is the same as an rdf:Bag resource, except the order of its member is significant. For instance, if we want to show which criterion is more important than the others, we will have to represent them using rdf:Seq.
However, items in this container are alternatives. For example, it can be used to describe a list of alternative stores where you can find a Nikon D camera. Let us take a look at the example shown in List 2. Furthermore, rdf:li is used to identify the members of this container resource, as shown in lines 11— Note that lines 7—16 represent one single statement, with the container resource represented by a blank node. In this case, since the members are contained in an rdf:Bag, these numbers should be ignored by the applications creating or processing this graph.
Note that RDF models do not regulate the processing of List 2. The syntax and graph representation of rdf:Alt are also exactly the same except that you need to use rdf:Alt as the type of the container resource. In fact, this container vocabulary is created with the goal to help make data representation and processing more interoperable; applications are not required to use them. They can choose their own way to describe groups of resources if they prefer.
The problem with an RDF container is that it is not closed: a container includes the identified resources as its members, it never excludes other resources to be members. Therefore, it could be true that some other RDF documents may add additional members to the same container. To solve this problem, RDF uses a pre-defined collection vocabulary to describe a group that contains only the specified resources as members. Note how the blank nodes are used in this structure Fig. Obviously, there is no way to add any new members into this container, since other RDF documents will not be able to access the blank nodes here.
Since ideally every closed container should follow the same pattern as shown in Fig. More specifically, there is no need to explicitly use rdf:first, rdf:rest, and rdf:nil keywords; all we need to do is to use the attribute rdf:parseType with its value set to be Collection, as shown in List 2. Note that it is possible, however, to manually use rdf:first, rdf:rest, and rdf:nil keywords to construct a close container, without using the notation shown in List 2.
If you decide to do so, it is your responsibility to make sure you have created the pattern as shown in Fig. In this section, we will discuss the remaining terms, more specifically, rdf:statement, rdf:subject, rdf:predicate, and rdf:object. In fact, these four terms make up the built-in vocabulary used for describing RDF statements. For example, for a given RDF statement, we might want to record information such as when this statement is created and who has created it.
A description of a statement using this vocabulary is often called a reification of the statement, and accordingly, this vocabulary is also called RDF reification vocabulary. Let us take a look at one example. The following statement from List 2. A reification of this statement is shown in List 2. Obviously, this reification example has used four statements to describe the original statement. This usage pattern is often referred to as the conventional use of the RDF reification vocabulary.
Since it always involves four statements, it is also called a reification quad. Now, to record provenance information about the original statement, we can simply add additional statement to this quad, as shown in List 2.
A Developer’s Guide to the Semantic Web
We will discuss Dublin Core in more detail in the next section. For now, understand that dc:creator represents the creator of a given document is good enough. You can certainly add more statement into List 2. The usage of reification vocabulary is fairly straightforward. However, it does require some caution when using it.
However, this kind of logic connection only exists in our mind. As a result, it is up to the RDF application to handle this, and it has to be done with care. For example, given the statements in List 2. However, there could be multiple statements in different RDF models, and all these statements will be matched successfully, and it is therefore hard to decide exactly which one is the candidate.
For example, different camera reviewers can make the same statement in their reviews in RDF format , and our RDF application built on all these reviews will find multiple matches. Therefore, for a given statement, we cannot simply depend on matching its rdf:subject, rdf:predicate, and rdf:object components.
Most likely, more application-specific assumptions may have to be made to make this work. In addition, note that other applications receiving these RDF documents may not share the same application-specific understanding, and therefore may not be able to interpret these statements correctly. With all these being said, RDF reification is still useful and remains an important topic, mainly because it provides one way to add provenance information, which is important to handle the issue of trust on the Web. For now, understand it, and in your own development work, use it with care. For instance, it is hard to read and can be quite long as well.
In addition, N-Triples is another simpler format than both Notation-3 and Turtle, and therefore offers another alternative to developers. In this section, we will focus mainly on Turtle format because of its popularity among developers. In addition, as you will see in Chap. It is a text-based syntax for serialization of RDF model. First off, a Turtle document is a collection of RDF statements, and each statement has a format that is called a triple:.
A given literal may have a language or a datatype URI as its suffix, but it is not allowed to have both. If it is given a language suffix, the suffix is created by a together with the language tag. For example, these two literals are perfectly legal: "10" "foo" 2. And this is the main idea for Turtle. However, there are lots of abbreviations and shortcuts that can make the RDF Turtle documents much more compact and still readable. Let us discuss these features next. The general format for defining namespace prefix is given as below: prefix pref:. For example, prefix foaf:.
These are obviously much more readable and compact as well. To create a default namespace, we can use the same general form, but without a pref string: prefix :. In other words, any URI identifier starting with : will be in the default namespace. Note in some document, base directive is also used to allow abbreviation of URIs.
It could be confusing if you are not familiar with this since it somewhat feels like default namespace prefix, but in fact it is not. Let us talk about this a little bit more. The key point to remember about base is this: whenever it appears in a document, it defines the base URI against which all relative URIs are going to be resolved.
Let us take a look at List 2. How should this be resolved? Clearly, line 1 is a triple that all of its components are using relative URIs; therefore, all these URIs should be resolved against the current base value. Since there is no explicit definition of base yet, the location of this document will be treated as the current base. Note pred1 does not need to resolve, since it has an absolute URI. Now, line 4 again uses base to define a relative URI, which will be resolved against the current base; in other words, line 4 is equivalent to the following: base. Line 6 defines a default namespace prefix: predix :.
Therefore, this default namespace will have the following resolved URI: predix :. Therefore, the triple on line 7 will be resolved to this:. Finally, line 8 defines another default namespace, and since it is an absolute URI already, it does not have to be resolved against the current base, and line 9 is resolved to this:. This should have cleared up the confusion around base directive and default namespace prefix, and this has also completed the discussion about URI abbreviation.
Let us talk about some other frequently used abbreviations. Both commas and semicolons can be used to make a given document shorter.
Autres bases documentaires
More specifically, if two or more statements with the same subject and predicate are made, we can combine the statements and separate different objects by one or more commas. For example, consider List 2. It can be changed to List 2. If we have the same subject but different predicates in more than one statements, we can use semicolons to make them shorter.
For example, List 2. Some literature does not recommend using blank nodes, but in some cases, they could be very handy to use. In Turtle, a blank node is denoted by  and you can use it as either the subject or the object. We can also use blank node to represent an object. For example, the Turtle statement in List 2. You can tell how compact the Turtle format is! There are altogether three basic rules, and they are critically related to some of the most important aspects of the Semantic Web.
At this point, these closely related aspects are as follows: 1. RDF represents and models information and knowledge in a way that machine can understand. Distributed RDF graphs can be aggregated to facilitate new information discovery. In this section, we will examine the three basic RDF rules. The goal is to establish a sound understanding of why these basic RDF rules provide the foundation to the above aspects of the Semantic Web. We have seen this rule already, where it was presented to describe the abstract RDF model. Here we will look at it again from a different perspective: it plays an important role when making machines understand the knowledge expressed in RDF statements.
Here is this rule again: Rule 1: Knowledge or information is expressed as a list of statements, each statement takes the form of Subject-Predicate-Object, and this order should never be changed. Before we get into the details on this part, let us take a look at this triple pattern once more time. Since the value of a property can be a literal or a resource, a given RDF statement can take the form of alternating sequence of resource—property, as shown in List 2.
Furthermore, resource-1 has a property named property-1 whose value is yet another resource described using lines 5—9. Arshad Iqbal.
Spark: The Definitive Guide. Bill Chambers. Programming Perl. Tom Christiansen. Brian Overland. Think Python. Allen B. Writing High-Performance. NET Code, 2nd Edition. Ben Watson.
- Neuroprotection: Models, Mechanisms and Therapies.
- Small Animal Imaging: Basics and Practical Guide.
- More titles to consider.
- Animal Behavior: An Introduction to Behavioral Mechanisms, Development, and Ecology?
- Join Kobo & start eReading today!
- The Austro-Hungarian Forces in World War I: 1914-16.
- Knowledge Wiki.
Simon Riggs. Andrei Alexandrescu. Stephen C. PostgreSQL 9. Gregory Smith. Python: Real-World Data Science. Dusty Phillips. Design Patterns for Embedded Systems in C. Bruce Powel Douglass. Rex Jones. Parallel and Concurrent Programming in Haskell. Simon Marlow. Introduction to Database Management System. Satinder Bal Gupta. Programming Windows Azure. Sriram Krishnan. The Practice of Programming. Len DiMaggio. Ben Klemens. Smalltalk Best Practice Patterns. Kent Beck. Programming WCF Services. Juval Lowy. Tomcat: The Definitive Guide. Jason Brittain.
Beginning C for Arduino, Second Edition. Jack Purdum. Aleksey Gurtovoy. Bob DuCharme. Steve Ries. Ronald J. ElasticSearch Server. Rafal Kuc'. Instant Debian Build a Web Server. Jose Miguel Parrella. Marc Gregoire. Introduction to Computer Science. Mark McIlroy.
Hrishikesh Vijay Karambelkar. Liferay Portal Performance Best Practices. Samir Bhatt. Exploring Big Historical Data. Shawn Graham. Mizanur Rahman. Cloud Computing. Christian Baun. Artificial Intelligence Programming. Eugene Charniak.
Related A Developer’s Guide to the Semantic Web
Copyright 2019 - All Right Reserved