Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
121 views31 pages

RDF & XML Technologies Overview

This document covers key concepts of the Semantic Web, focusing on the Resource Description Framework (RDF) and various XML technologies such as XPath, XSL, XSLT, and XQuery. It explains how RDF triples are used to represent relationships between resources and the importance of XML technologies in transforming and querying XML data. Additionally, it discusses the roles of XLink, XPointer, and XInclude in linking and including XML documents, highlighting their significance in creating a more interconnected web of data.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
121 views31 pages

RDF & XML Technologies Overview

This document covers key concepts of the Semantic Web, focusing on the Resource Description Framework (RDF) and various XML technologies such as XPath, XSL, XSLT, and XQuery. It explains how RDF triples are used to represent relationships between resources and the importance of XML technologies in transforming and querying XML data. Additionally, it discusses the roles of XLink, XPointer, and XInclude in linking and including XML documents, highlighting their significance in creating a more interconnected web of data.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 31

SEMANTIC WEB

Unit-III
Syllabus
Resource Description Framework: Features, Capturing Knowledge with RDF.
XML Technologies: XPath, The Style Sheet Family: XSL, XSLT, and XSL FO, XQuery,
XLink, XPointer, XInclude, XMLBase, XHTML, XForms, SVG.

Introduction to RDF Language.


The XML tags can often add meaning to data, however, actually understanding the
tags is meaningful only to humans. For example, given the following segment of
XML markup tags:
<book>
<title>Godel, Escher, Bach: An Eternal Golden Braid
<title>
</book>

A human might infer that: “The book has the title G¨odel, Escher, Bach: An
Eternal Golden Braid.” This simple grammatical sentence is understood to contain
three basic parts: a subject [The book], a predicate [has title], and an object [G¨odel,
Escher, Bach: An Eternal Golden Braid]. A machine, however, could not make this
inference based upon the XML alone.
For machines to do more automatically, it is necessary to go beyond the notion of the
HTML display model, or XML data model, toward a “meaning” model. This is
where RDF and metadata can provide new machine-processing capabilities built
upon XML technology. What is metadata? It is information about other data.
Building upon XML, the W3C developed the RDF metadata standard. The goal was
to add semantics defined on top of XML.
RDF Triple
The RDF model is based on statements made about resources that can be anything
with an associated URI (Universal Resource Identifier). The basic RDF model
produces a triple, where a resource (the subject) is linked through an arc labeled with
a property (the predicate) to a value (the object).
The key elements of an RDF triple are as follows:
Subject:- In grammar, this is the noun or noun phrase that is the doer of the action.
In the sentence “The company sells batteries,” the subject is “the company.” The
subject of the sentence tells us what the sentence is about. In logic, this is the term
about which something is asserted. In RDF, this is the resource that is being
described by the ensuing predicate and object. Therefore, in RDF, we want a URI to
stand for the unique concept “company” like
“http://www.business.org/ontology/#company” to denote that we mean a form of
business ownership and not friends coming for a visit.
Predicate:- In grammar, this is the part of a sentence that modifies the subject and
includes the verb phrase. Returning to our sentence "The company sells batteries"
the predicate is the phrase "sells batteries" In other words, the predicate tells us
something about the subject. In logic, a predicate is a function from individuals (a
particular type of subject) to truth-values with an arity based on the number of
arguments it has. In RDF, a predicate is a relation between the subject and the
object. Thus, in RDF, we would define a unique URI for the concept "sells" like
“http://www.business.org/ ontology/#sells”.
Object:-In grammar this is a noun that is acted upon by the verb. Returning to our
sentence "The company sells batteries" the object is the noun "batteries" In
logic, an object is acted upon by the predicate. In RDF, an object is either a resource
referred to by the predicate or a literal value. In our example, we would define a
unique URI for "batteries" like “http://www .business.org/ontology/#batteries”.
Statement
In RDF, the combination of the preceding three elements, subject, predicate, and
object, as a single unit. Figure 5.3 displays a graph representation of two RDF
statements. These two statements illustrate the concepts in Figure 5.2. Note that the
object can be represented by a resource or by a literal value.
We should stress that resources in RDF must be identified by resource IDs, which
are URIs with optional anchor IDs. This is important so that a unique concept can be
unambiguously identified via a globally unique ID. This is a key difference between
relying on semantics over syntax. The syntactic meaning of words is often
ambiguous. For example, the word “bark” in the sentences “The bark felt rough” and
“The bark was loud” has two different meanings; however, by giving a unique URI
to the concept of tree bark like “www.business.org/ontology/plant/#bark”, we can
always refer to a single definition of bark.
Figure 5.4 displays an IsaViz graph of the three RDF statements.
While the triple is the centerpiece of RDF, other elements of RDF offer
additional facilities in composing these knowledge graphs.
XML Technologies
XPath

XPath is the XML Path Language, and it plays an important role in the XML family of
standards. It provides an expression language for specifically addressing parts of an XML
document. XPath is important because it provides key semantics, syntax, and
functionality for a variety of standards, such as XSLT, XPointer, and XQuery. By using
XPath expressions with certain software frameworks and APIs, you can easily reference
and find the values of individual components of an XML document.
W3C Recommendation written in 1999, XPath 1.0 was the joint work of the W3C XSL
Working Group and XML Linking Working Group, and it is part of the W3C Style
Activity and W3C XML Activity. In addition to the functionality of addressing areas of
an XML document, it provides basic facilities for manipulation of strings, numbers, and
booleans. XPath uses a compact syntax to facilitate its use within URIs and XML
attribute values. XPath gets its name from its use of a path notation as in URLs for
navigating through the hierarchical structure of an XML document. Because we can use
XPath to specifically address where components can be defined, it provides an important
mechanism that is used by other XML standards and larger XML frameworks and APIs.

Role played by XPath in other standards


1. With XSLT, you can define a template in advance using XPath expressions that allow
you to specify how to style a document.
2. XQuery is a superset of XPath and uses XPath expressions to query XML native
databases and multiple XML files.
3. XPointer uses XPath expressions to “point” to specific nodes in XML documents.
4. XML Signature, XML Encryption, and many other standards can use XPath
expressions to reference certain areas of an XML document.
5. In a Semantic Web ontology, groups of XPath expressions can be used to specify how
to find data and the relationships between data.
6. The DOM Level 3 XPath specification, a Working Draft from the W3C, also provides
interfaces for accessing nodes of a DOM tree using XPath expressions.
The Style Sheet Family: XSL, XSLT, and XSLFO

Style sheets allow us to specify how an XML document can be transformed into new
documents, and how that XML document could be presented in different media formats.
The languages associated with style sheets are
1. XSL (Extensible Stylesheet Language),
2. XSLT (Extensible Stylesheet Language: Transformations), and
3. XSLFO (Extensible Stylesheet Language: Formatting Objects)

A style sheet processor takes an XML document and a style sheet and produces a result.
XSL consists of two parts: It provides a mechanism for transforming XML documents
into new XML documents (XSLT), and it provides a vocabulary for formatting objects
(XSLFO). XSLT is a markup language that uses template rules to specify how a style
sheet processor transforms a document and is a Recommendation by the W3C.
It is important to understand the importance of styling. Using style sheets adds presentation
to XML data. In separating content (the XML data) from the presentation (the style
sheet), you take advantage of the success of what is called the Model-View- Controller
(MVC) paradigm. The act of separating the data (the model), how the data is displayed
(the view), and the framework used between them (the controller) provides maximum
reuse of your resources. When you use this technology, XML data can simply be data.
Your style sheets can transform your data into different formats, eliminating the
maintenance nightmare of trying to keep track of multiple presentation formats for the
same data. Embracing this model allows you to separate your concerns about maintaining
data and presentation. Because browsers such as Microsoft Internet Explorer have style
sheet processors embedded in them, presentation can dynamically be added to XML data
at download time.
Figure 6.2 shows a simple example of the transformation and formatting process. A style
sheet engine (sometimes called an XSLT engine) takes an original XML document, loads
it into a DOM source tree, and transforms that document with the instructions given in
the style sheet. In specifying those instructions, style sheets use XPath expressions to
reference portions of the source tree and capture information to place into the result tree.
The result tree is then formatted, and the resulting XML document is returned. Although
the original document must be a well-formed XML document, the resulting document
may be any format. Many times, the resulting document may be postprocessed. In the
case of formatting an XML document with XSLFO styling, a post-processor is usually
used to transform the result document into a different format (such as PDF or RTF etc).
The resulting document is rendered dynamically in the Internet Explorer browser,
shown in Figure 6.3.

Why are style sheets important?


In an environment where interoperability is crucial, and where data is stored in different
formats for different enterprises, styling is used to translate one enterprise format to
another enterprise format. In a scenario where we must support different user interfaces
for many devices, style sheets are used to add presentation to content, providing us with a
rich mechanism for supporting the presentation of the same data on multiple platforms.
Figure 6.4 shows a diagram of many practical examples of style sheets in use. In this
diagram, different style sheets are applied to an XML document to achieve different
goals of presentation, interoperation, communication, and execution. At the top of the
diagram, you see how different style sheets can be used to add presentation to the original
XML content. In the case of XSLFO, sometimes a post-processor is used to transform the
XSLFO vocabulary into another format, such as RTF and PDF. In the “interoperation”
portion of Figure 6.4, a style sheet is used to transform the document into another format
read by another application. In the “communication” portion of Figure 6.4, a style sheet
is used to transform the XML document into a SOAP message, which is sent to a Web
service. Finally, in the “execution” section, there are two examples of how XML
documents can be transformed into code that can be executed at run time.
These examples should give you good ideas of the power of style sheets.
XQuery

XQuery is a language designed for processing XML data, and it is intended to make
querying XML-based data sources as easy as querying databases. Although there have
been attempts at XML query languages before—such as XQL, XML-QL, and Quilt—
XQuery, a product of the W3C, is the first to receive industry-wide attention. The Query
Working Group of the W3C has made it clear that there is a need for a human-readable
query syntax, and there is also a requirement for an XML-based query syntax. XQuery
was designed to meet the human-readable syntax requirement. It is an expression
language that is an extension of XPath. With few exceptions, every XPath expression is
also an XQuery expression.
Similar to using style sheet transformations, the XQuery process uses XPath expressions
and its own functions to query and manipulate XML data. It is a strongly typed language,
and its syntax is very similar to a high-level programming language, such as Perl. To
demonstrate how XQuery works, we will use the example XML file shown in Listing 6.1.
The following is a valid
As you can see by the result of the XQuery expression, the <workday> elements have now
been sorted alphabetically based on their <description> child element. XQuery is important
because it will provide a standard query interface to XML databases and data stores.
XQuery is currently in Working Draft status at the W3C (http://www.w3.org/TR/xquery/),
and it is continuing to evolve.
XLink
XLink is the XML Linking Language from the W3C. It allows elements to be inserted into
XML documents in order to create and describe links between resources, associate meta
data, and link external documents. Part of the specification is similar to hyperlinks in
HTML, but XLink goes far beyond the linking capabilities in HTML in offering advanced
behavior features that make hyperlinking more flexible. XLink allows you to link multiple
targets, roles, resources, and responses to elements.
In Listing 6.3, we have an example that discusses employers and courses in a document.
Throughout the XML file, the xlink:type attribute of the element is set to ‘simple’, and
the xlink:href attribute is set to link to external documents and to elements within the
document. This is the simplest example of linking.
XLink can also connect relationships together. If, for example, we wanted to link
descriptions with our courses and employers, we could use the XLink ‘extended’ link
type to connect our descriptions with our elements. A bit more complicated than the
simple links shown in Listing 6.3, extended links allow arcs to describe relationships
between elements and remote resources. Listing 6.4 shows an example of our simple
XLink example from Listing 6.3 modified to incorporate relationships between some of
the elements.
In Listing 6.4, adding the <extendedlink> element with the xlink:type attribute of
‘extended’ allows us to make relationships between the elements. In the example, an
‘arc’ xlink:type attributes allow us to connect a course with its description, an employer,
and a description.
What is XLink’s importance?
It is the W3C’s recommendation for generic linking, and it is intended for use in
hypertext systems. Languages such as Scalable Vector Graphics (SVG) and MathML use
XLink for hypertext references. At this point, the Resource Directory Description
Language (RDDL) uses XLink syntax to specify the relationship between URLs and
other resources. It is the intention of the W3C that XLink be used for generic linking
mechanisms in XML languages.
XPointer
XPointer is the XML Pointer Language from the W3C, which is used as a fragment
identifier for any URI reference that locates an XML-based resource. A powerful
language, XPointer can “point” to fragments of remote documents using XPath
expressions and can point to ranges of data and points of data in documents.
An example of using XPointer is shown in Listing 6.5, where we can rewrite the data
contained in the <extendedlink> element of Listing 6.4. As you can see, XPointer
expressions are used in the xlink:href attributes of the <loc> element in order to point
directly to the elements. The links address the <company> element with an ID “mcbrad”
and a <course> element with the ID attribute of “CS593”.

That expression points to every ‘Truck’ string in the document. Looking at our earlier
Listing 6.1, that expression would point to the ‘Truck’ string in the text node ‘Rebuilding
a 1967 Pickup Truck’ in the <description> element, as well as the ‘Truck’ string in the
‘Taking Truck Body Apart’ node, shown later in the document. XPointer is a powerful
specification, and it offers a rich mechanism for addressing pieces of XML documents.
In the summer of 2002, the XML Linking Group of the W3C broke the XPointer
specification into four Working Draft pieces:
1. An XPointer core framework.
2. The XPointer element() scheme for addressing XML elements.
3. The XPointer xmlns() scheme to allow correct interpretation of namespace prefixes in
pointers, and
4. The XPointer xpointer() scheme for full XPointer addressing flexibility.

Both XLink and XInclude can use XPointer expressions, and it is likely that there will be
more adoption into products and other specifications.
XInclude

XML Inclusions (XInclude) is a W3C Candidate Recommendation used for the purpose
of including documents, elements, or other information in an XML document. With it,
you can build large XML documents from multiple fragmentary XML documents, well-
formed XML documents, or non-XML text documents. It also has a “fallback” feature in
case the external document is not available or the server is down. The simplest example
of this is shown in the following, where the beginning of this chapter could be separated
in multiple files:

This code is very basic. External XML files for each chapter section are included in one
document with XInclude. The rendered version would look like a large document.
XInclude is a bit more powerful than that, however. Listing 6.6 gives a more complex
example where non-XML content and portions of documents can be brought into an
XML document, and where the XInclude “fallback” mechanism is used
Support for XInclude is limited, but it is growing. Many in the XML community are
looking at security implications of browser-based XInclude, because there could be
potential misuses.
XML Base
XML Base is a W3C Recommendation that allows authors to explicitly specify a
document’s base URI for the purpose of resolving relative URIs. Very similar to
HTML’s base element, it makes resolving relative paths in links to external images,
applets, form-processing programs, style sheets, and other resources. Using XML Base,
an earlier example in the last section could be written the following way:
XHTML
XHTML, the Extensible Hypertext Markup Language, is the reformulation of HTML
into XML. The specification was created for the purpose of enhancing our current Web
to provide more structure for machine processing. Why is this important? Although
HTML is easy for people to write, its loose structure has become a stumbling block on
our way to a Semantic Web. It is well suited for presentation for browsers; however, it is
difficult for machines to understand the meaning of documents formatted in HTML.
Because HTML is not well formed and is only a presentation language, it is not a good
language for describing data, and it is not extremely useful for information gathering in a
Semantic Web environment. Because XHTML is XML, it provides structure and
extensibility by allowing the inclusion of other XML-based languages with namespaces.
By augmenting our current Web infrastructure with a few changes, XHTML can make
intermachine exchanges of information easier.
XHTML 1.0, a W3C Recommendation released in January 2000, was a reformulation of
HTML 4.0 into XML. The transition from HTML to XHTML is quite simple. Some of
the highlights include the following:

1. An XHTML 1.0 document should be declared as an XML document using an XML


declaration.
2. An XHTML 1.0 document is both valid and well formed. It must contain a
DOCTYPE that denotes that it is an XHTML 1.0 document, and that also denotes
the
DTD being used by that document. Every tag must have an end tag.
3. The root element of an XHTML 1.0 document is <html> and should contain a
namespace identifying it as XHTML.
4. Because XML is case-sensitive, elements and attributes in XHTML must be
lowercase.
The difference between Listings 6.7 and 6.8 shows that this transition between HTML
and XHTML is quite smooth. Because XHTML 1.0 is well formed and valid, it can be
processed easier by user agents, can incorporate stronger markup, and can reap the
benefits of being an XML-based technology.
In XML, it is easy to introduce new elements or add to a schema. XHTML is designed
to accommodate these extensions through the use of XHTML modules. XHTML 2.0, a
W3C Working Draft released in August 2002, is made up of a set of these modules
that describe the elements and attributes of the language. XHTML 2.0 is an evolution
of XHTML 1.0, as it is not intended to be backward-compatible.
SVG
Scalable Vector Graphics (SVG) is a language for describing two-dimensional graphics
in XML. A W3C Recommendation since September 2001, there are many tools and
applications that take advantage of this exciting technology. With SVG, vector graphics,
images, and text can be grouped, styled, and transformed. Features such as alpha masks,
filter effects, and nested transformations are in this XML-based language, and animations
can be defined and triggered. Many authors use scripting languages that access the
SVG’s Document Object Model to perform advanced animations and dynamic graphics.
The potential for SVG is quite exciting. Because it is an XML language, data content can
be transformed into SVG to create graphically intense programs and animations. Online
maps can easily convey the plotting of data, roads, and buildings with SVG.

Listing 6.11, an example taken from the SVG Recommendation of the W3C, creates an
image of a red ellipse, shown in Figure 6.7. When a user clicks on the ellipse, the user is
taken to the W3C Web site. Of course, this is one of the simplest examples. SVG takes
advantage of XLink for linking.

If product adoption is any indicator, the SVG specification is quite successful. In a very
short time, vendors have jumped on the SVG bandwagon. The Adobe SVG Viewer, the
Apache Batik project, the SVG-enabled Mozilla browser, the W3C’s Amaya
editor/browser, and Jasc’s WebDraw applicationsupport SVG, to name a few.
XForms
XForms is a W3C Candidate Recommendation that adds new functionality,
flexibility, and scalability to what we expect to existing Web-based forms.
Dubbed “the next generation of forms for the Web,” XForms separates presentation from
content, allows reuse, and reduces the number of round-trips to
the server, offers device independence, and reduces the need for scripting in
Web-based forms.6 It separates the model, the instance data, and the user interface into
three parts, separating presentation from content.
Web forms are everywhere. They are commonplace in search engines and e-commerce
Web sites, and they exist in essentially every Web application. HTML has made forms
successful, but they have limited features. They mix purpose and presentation, they run
only on Web browsers, and even the simplest form-based tasks are dependent on
scripting. XForms was designed to fix these shortcomings and shows much promise.
uses the isValid attribute to validate the form. In this case, if someone attempts to submit
the information without typing in anything, it will throw an invalid XForm event. Also
notice that in the body of the document, individual components of the model are
referenced by XPath expressions (in the ref attribute of the input elements)

You might also like