Web Ontology Language (OWL) is a markup language for publishing and sharing data using ontologies on the Internet. OWL is a vocabulary extension of the Resource Description Framework (RDF) and is derived from the [[DAML+OIL]] Web Ontology Language (see also DAML and OIL). Together with RDF and other components, these tools make up the Semantic Web project.

OWL represents the meanings of terms in vocabularies and the relationships between those terms in a way that is suitable for processing by software.

The OWL specification is maintained by the World Wide Web Consortium (W3C).

OWL is seen as a major technology for the future implementation of a Semantic Web. OWL was designed specifically to provide a common way to process the content of web information. The language is intended to be read by computer applications instead of by humans. And because OWL is written in XML, OWL information can be easily exchanged between different types of computers using different operating systems, and application languages. OWL’s main purpose will be to provide standards that provide a framework for asset management, enterprise integration and the sharing and reuse of data on the Web. OWL was developed mainly because it has more facilities for expressing meaning and semantics than XML, RDF, and RDF-S, and thus OWL goes beyond these languages in its ability to represent machine interpretable content on the web. [1]

OWL currently has three flavors (sometimes also referred to as ’species’): OWL Lite, OWL DL, and OWL Full. These flavors incorporate different features, and in general it is easier to reason about OWL Lite than OWL DL and OWL DL than OWL Full. OWL Lite and OWL DL are constructed in such a way that every statement can be decided in finite time; OWL Full can contain endless ‘loops’.

History of OWL

A number of research efforts during the mid to late 1990s explored how the idea of knowledge representation from AI could be made useful on the World Wide Web. These included languages based on HTML (called SHOE), XML (called XOL, later OIL), and various frame-based KR languages and knowledge acquisition approaches.

OWL DL is based in part on the description logic and also on a number of earlier KR systems known as frame-based systems. Its subset OWL Lite is based on the less expressive logic . All reasoning tasks in both OWL DL and OWL Lite can be reduced to knowledge based (KB) satisfiablity. OWL Full operates outside the bounds of Description Logic, allowing more power and expressivity and having less constraints on use, but at the cost of decidability. (OWL Full’s semantics is based on the Semantics of RDF) OWL is encoded in RDF/XML documents.

The OWL Language is a revision of the DAML+OIL web ontology language incorporating learnings from the design and application use of DAML+OIL. DAML+OIL was developed by a group called the “US/UK ad hoc Joint Working Group on Agent Markup Languages” which was jointly funded by the US Defense Advanced Research and Development Agency (DARPA) under the DAML program and the EU’s IST funding project.

The World Wide Web Consortium created the “Web Ontology Working Group” which began work on November 1, 2001 chaired by James Hendler and Guus Shreiber. The first working drafts of the abstract syntax, reference and synopsis were published in July 2002. The OWL documents became a formal W3C recommendation on February 10, 2004 and the working group was disbanded on May 31, 2004.[3]

Within the working group, effort to identify design goals and requirements was led by Jeff Heflin. Some of the requirements were contributed by Deborah McGuinness based upon over a decade of work in building ontology-based systems. Other requirements were identified as part of Heflin’s Ph.D. thesis work in building a prototype Semantic Web system. The other members of the working group contributed over 25 use cases, which were later boiled down into defining a set of use cases. (For example, a draft version of the Corporate Web Site Management section was written by Michael Smith, a use case on agent-based computing was developed by Tim Finin, etc.).[4]

Continue reading article on Informat

This article gives an overview of data binding in the .NET framework. Microsoft has beefed up the data binding features considerably in .NET which has made data binding a compelling option to tie your front-end to data sources. I have concentrated on .NET windows forms data binding.

What is DataBinding?

DataBinding is a powerful feature provided by the .NET framework that enables visual elements in a client to connect to a datasource such as DataSets, DataViews, Arrays etc. Some of the visual elements in the client can be TextBox, Datagrid etc. A two-way connection is established such that any changes made to the datasource are reflected immediately in the visual element and vice versa.

DataBinding Before .NET

In the earlier databinding models, the datasource that could be used was usually limited to a database. All DBMS systems provided their own API’s to help in building GUI applications and quickly bind them to the data. Programmer did not have the flexibility to control the databinding process with the result that most developers avoided the use of databinding.

DataBinding with .NET

The .NET framework provides a very flexible and powerful approach to databinding and allows the programmer to have a fine control over the steps involved in the whole process. One of the biggest improvements with .Net has been the introduction of databinding to web pages through the use of .Net server-side web controls. Hence, building data driven web applications has been greatly simplified. Please note that this article only deals with data binding in .NET windows forms.

Advantages of DataBinding

1. Databinding in .NET can be used to write data driven applications quickly. .NET data binding allows you to write less code with fast execution but still get the work done in the best way.
2. .NET automatically writes a lot of databinding code for you in the background (you can see it in “Windows Generated Code” section), so the developer does not have to spend time writing code for basic databinding, but still has the flexibility of modifying any code that he would like to. We get the benefits of bound as well as unbound approach.
3. Control over the Databinding process by using events. This is discussed in more detail later in the article.

Read more on Databinding Concepts and Databinding Disadvantages on Code Project.

Uche Ogbuji wrote a good article on XML.com here is a summary: “I’m still getting my Weblogger profile here updated, but this year I transitioned from one company I co-founded to another. Zepheira provides data architecture solutions, with a focus on semantic technology. I was early on the Semantic Web bandwagon, and I almost fell off at one point because I felt the useful, modest ideas at the core had been overrun by an academic brand of technological megalomania. This year I felt the timing was right to not only renew my interest in the technology, but to stake my livelihood on it. Part of it was timing: I was starting to see the more useful underpinnings of semantic technology take hold in corporations. Part of it was people: I found a group of professionals who I believed were capable of building practical semantic technology solutions, and, more importantly, selling them.”

“One of those people, Eric Miller, former chair of the W3C Semantic Web Activity, is especially well known for describing the benefits of semantic technology in terms executives can appreciate, and he’s featured in a new InternetWeek article “The Semantic Web Goes to Work”. The article says: “You[’d] better figure out what the Semantic Web is and soon, because its concepts have graduated from academia and are starting to contribute to your competitor’s bottom line.”

Keep reading Ogbuji’s article on XML.com

This document specifies version 1 of the Synchronized Multimedia Integration Language (SMIL 1.0, pronounced “smile”). SMIL allows integrating a set of independent multimedia objects into a synchronized multimedia presentation. Using SMIL, an author can

1. describe the temporal behavior of the presentation
2. describe the layout of the presentation on a screen
3. associate hyperlinks with media objects

This specification is structured as follows: Section 2 presents the specification approach. Section 2 defines the “smil” element. Section 3 defines the elements that can be contained in the head part of a SMIL document. Section 4 defines the elements that can be contained in the body part of a SMIL document. In particular, this Section defines the time model used in SMIL. Section 5 describes the SMIL DTD.
Status of this Document

This document is a W3C Working Draft produced by the W3C Working Group on Synchronized Multimedia (SYMM). This document is [soon to be] undergoing review by the Members of the World Wide Web Consortium. It is a stable document derived from a series of working drafts produced over the last year as deliverables of the Synchronized Multimedia activity. Details of this review have been distributed to Member’s representatives. Comments by non-Members should be sent to www-smil@w3.org.

For most of the features in this specification, interoperability of independently developed implementations has been demonstrated at an interoperability meeting. Implementation of the remaining features is in progress. Endorsement of this specification as a W3C Recommendation is contingent on demonstration of interoperability for the remaining features.

Specification Approach

SMIL documents are XML 1.0 documents [XML10]. The reader is expected to be familiar with the concepts and terms defined in XML 1.0.

This specification does not rely on particular features defined in URLs that cannot potentially be expressed using URNs. Therefore, the more generic term URI [URI] is used throughout the specification.

The syntax of SMIL documents is defined by the DTD in Section 5.2. The syntax of an attribute value that cannot be defined using the DTD notation is defined together with the first element using an attribute that can contain the attribute value. The syntax of such attribute values is defined using the Extended Backus-Naur Form (EBNF) defined in the XML 1.0 specification.

An element definition is structured as follows: First, all attributes of the element are defined in alphabetical order. An attribute is defined in the following way: If the attribute is used by an element for the first time in the specification, the semantics of the attribute are defined. If the attribute has already been used by another element, the specification refers to the definition of the attribute in the first element that used it. The definition of element attributes is followed by the definition of any attribute values whose syntax cannot be defined using the DTD notation. The final section in an element definition specifies the element content.

Source : Coverpages

HTML is very easy to use; it was designed that way. You don’t have to be a programmer to use it. If you can edit a text file, then you can write HTML (and if you can write email, you can edit a text file). If you tried to learn before and couldn’t, then someone wasn’t telling you the right things.

This tutorial will explain the structure of HTML quickly and clearly, and show you through examples the practical things you need to know, so you can be making your own pages soon (like, this afternoon). The whole tutorial is about 14 printed pages, but you only need the first four or so to be off and running.

In this tutorial, you’ll create small pages and view them. There aren’t really any “required” exercises, but you should play with new concepts until you’re comfortable with them. If your browser supports frames, fire up this HTML Test Bed (non-frames version), where you can type HTML in one frame and see the resulting page in another. Resize the input and output frames/windows for best viewing.

If your browser doesn’t support frames, or when you’re making real pages, you’ll want a real text editor. Start up TeachText on the Mac, pico in Unix, or Notepad in Windows, or a better one if you have it (here’s a directory of text editors at Yahoo). Give your HTML files names ending in “.html” (or “.htm”). Use your browser to view the HTML files you create, with the menu command “File/Open File” or something similar; use the “Reload” function after each change.

Learn more on HTML on Marshall.com

An old saying goes: “There are two types of people: those who divide people into two types and those who don’t.” I am definitely in the former group. For example, I might say there are two types of people: those who read Web pages and those who create them. Of course, some of us do both, but the vast majority of the Web-using public doesn’t know or care about the messy underpinnings of HTML, Web servers, browser compatibility issues, and all the rest. They care about just one thing: the information on the page. If a page loads too slowly, if the fonts are too small, if the graphics overlap the text, or if any of a thousand other things goes wrong, the average Web surfer will simply move along to the next page—there’s nearly always another source for any piece of information, and life is too short to waste it on poorly designed Web sites.

Strangely, this fact seems to be lost on a great many Web developers. I’m surely not alone in having made many purchasing decisions based on the clarity, accessibility, or convenience of a company’s Web site. And when I list URLs for related pages at the bottom of an article on this site, I exclude sites that play music incessantly, that don’t show up correctly in my browser, or that otherwise annoy me. I figure they’ll annoy you too. This is a shame, because the whole point of the Web was to make information available to as many people as possible—and clearly, on some level at least, that goal is still not being achieved.

There are many ways of designing Web pages, but among these are certain widely recognized “best practices.” One such practice is the use of something called Cascading Style Sheets, or CSS for short. If you’re a Web developer, this technology is very old news; if not, your eyes may even now be glazing over as you anticipate a description of meaningless codes and standards that will have no effect on your life at all. I’ll keep this as non-technical as I can; I mainly want to make three points: first, CSS is a wonderful and magical thing; second, any Web site that doesn’t use CSS, should; and third, most sites that do use CSS—including this one—could do a better job. Effective use of CSS improves the Web for everyone—reader and creator alike.

I’m not going to tell you how to make a style sheet or why they “cascade”—there are lots of places to learn that. What I want to tell you is why Cascading Style Sheets are interesting—and why they are so badly needed.

In the Beginning There Was the Page

The first Web pages were mainly concerned with presenting straightforward subject matter to a technically competent audience, not advertising all the world’s books or trying to sell you a car. The people who decided how Web pages should be made—the World Wide Web Consortium, or W3C—designed the original specifications to reflect the needs of early users who worked with simple and highly structured information such as technical papers, outlines, bibliographies, and tables. As the Web became more commercialized, a whole new group of people began creating Web pages. The new Web designers were, on the whole, neither academics nor programmers, but ordinary people who thought Web pages should mimic the layouts found in other media. Unfortunately, the early W3C specifications didn’t provide any way for these new designers to exert the level of control they wanted, so two things happened. On the one hand, companies that made Web browsers started “coloring outside the lines,” so to speak, implementing features that were not part of the official specification. And second, Web designers began to use parts of the specification in ways that were never intended—let’s be bold and call it “cheating”—in order to trick browsers into displaying exactly what they wanted on the screen.

To some extent this cheating worked, but not all browsers performed the same sets of tricks or in the same way—nor did all designers use exactly the same methods of cheating. The result was pages that looked fine in one browser but not another, or on one computer but not another. In order to deal with the chaos, the W3C said fine, let’s update the specification to officially sanction many of the unorthodox cheats. Then at least everyone will be doing the same thing. And so, over the years, the specification went through many revisions, as did browsers, and as did the aesthetic sensibilities of Web designers. Today, on the whole, things are better than they were a few years ago, but there’s still a significant problem. Many Web pages are only friendly to a small group of people—typically, English-speaking people with good eyesight, large monitors, modern browsers, fast computers, and even faster internet connections. And the problem with that is that there are billions of people in the world who aren’t in that group. So if such a Web site provides information, some people can’t read it; if it sells something, there’s an artificial limit on the number of potential customers.

Orthodoxy and Reform

The W3C realized years ago that the specifications for creating Web pages were on a slippery slope, and began taking steps to bring sanity back to Web design. Their first step was to invent a good way for designers to separate the content of a Web site (the text and images) from its form (its layout and visual characteristics). They created two new specifications: one, called XHTML, for the way the content and structure of a site are represented—things like titles, headings, paragraphs, quotations, images, and so on—and a second, known as Cascading Style Sheets, for the way visual elements should appear, including text size, colors, spacing, and layout. And they basically said: “Follow these rules, and there will be joy.” The specifications were cleverly designed such that if Web designers followed them, all the older browsers that didn’t know anything about the newer specifications would still display the pages adequately—not beautifully, sure, but all the content would be readable. (Web pages that do this are said to “degrade gracefully.”)

Read Joe Kissell quality post on CSS

Not so long ago, font tags (which are evil) provided a web designer’s only means of formatting an HTML document’s text for presentation within web browsers such as Microsoft Internet Explorer™, Opera™ or Mozilla Firefox.

The trouble with font tags was that they were not only notoriously unreliable for presenting any given piece of information in the way initially intended by its author; they also bloated file sizes to almost insupportable proportions. In fact, even the text size setting of a browser could make a page’s content overlap or become unreadable in some other shape or form.

However, there’s a new sheriff in town; CSS (Cascading Style Sheets).
Although CSS was originally conceived in 1994 and has been a W3C recommendation since 1998, it has only gained any real degree of popularity during the past few years (since about 2003, if you happen to be reading this at some point in the future).

The notion behind CSS is to take the formatting work away from an HTML document and place it in a central file which controls the layout and appearance of an entire web site, although this concept has since grown well beyond its original intent (you may wish to look out for future articles on CSS controlled ‘no table’ design’).
In this way, content can be presented in a uniform manner, regardless of browser platform.

One fortunate side-effect of this approach is the dramatic reduction in the physical size of HTML documents. Whereas before, font tags (which are evil) were scattered throughout HTML code substantially increasing file sizes of individual web pages and generally making a nuisance of themselves, the application of CSS figuratively turned HTML from John Candy (anyone here old enough to remember him?) into Arnold Schwarzenegger; a lean, mean hombre who would think nothing of going into the Middle East and kicking some butt.

Continue this article on IceGaint

Accessing data on the Internet using current technology is slow. Pages are slow to render because they are being built by server processes. The processes building these pages are slowing down your server because your server is generating HTML rather than transmitting files. Since, on the client, the data in a page is indistinguishable from the page that contains it, additional requests are made to the server to manipulate the data.
Data binding is a new feature of Microsoft® Internet Explorer 4.0 (IE 4.0) that enables authors to create Web pages that are faster to render, more interactive, easier to author, and that require fewer server resources. It does this by using the Dynamic HTML support built into IE 4.0.

Dynamic HTML allows all the elements on a Web page to be manipulated through scripting languages. Data binding uses Dynamic HTML in conjunction with a simple declarative syntax to display data using standard HTML elements without resorting to complex scripting. Instead of the traditional method of merging the data with the HTML through server-side templates or CGI scripts before it’s sent to the browser, data binding performs this operation on the client after a page is received.

ata binding differs from traditional data publishing methodologies in that it uses standard HTML as a template for the data and merges the data with the template asynchronously as the data is transmitted to the client—like rendering a GIF—rather than building the entire page on the server. This results in a page that displays data incrementally as it’s transmitted to the client for faster initial response time. It also allows authors to create pages that build client/server applications using HTML elements without creating server-side CGI scripts to process the forms. With data binding, users can manipulate the data on the client without a round-trip to the server and without losing the context of the current page, giving the user a more interactive experience.

A Common Scenario for Data Binding

If you’re like me, an example is worth 30 pages of a manual. Consider a fairly common scenario: a brokerage firm that provides access to customers’ portfolios through the Web. The customer will want to see a list of the stocks in his portfolio and be able to sort that list by stock symbol, total asset value, number of shares, and so on. The customer may also want to limit the list of stocks viewed to those purchased in a single calendar year.
Before data binding, the author of the Web pages would have had to use CGI scripts or a template processor to construct three pages: one to display a list of stocks in the user’s portfolio, another to show the list sorted by symbol, and a third to display the list sorted by asset value. Moreover, to display the list of stocks for a single year, a fourth page would have to be created with an HTML form on it. The user then enters a year using this form and submit it to a server process (CGI or similar) which would then construct a page containing a list of stocks for the year requested. To give the user the ability to sort this new single-year list, the server would have to maintain which year was being viewed so the data could be sorted appropriately. Anyway, you get the idea. Lots of pages, lots of round-trips to the server, and transmission of the same data multiple times over a 28.8 Kbps modem.

f only the brokerage firm had used data binding, they could have created a single page to provide the entire set of functionality described above. The list of stocks in the customer’s portfolio would display more quickly because the data would be asynchronously rendered as it was transmitted to the client. Once the data was received by the client, it could be sorted and filtered directly on the client, without a round-trip to the server. The user wouldn’t have to wait for the same data to be transmitted over and over again just to change the sort order on the page. Redisplay would be virtually instantaneous.

Building a Page with Data Binding

The best way to understand data binding is to build a page that uses it. I’ll do that in this article using the scenario I described in the previous section. Along the way, I’ll explain the components of the Dynamic HTML data binding architecture for those of you who like to look under the hood as well as drive the car. The best part is, you’ll be able to write this code and experiment on your own today. Data binding is available in the Platform Preview of IE 4.0 at http://www.microsoft.com/ie/ie40/. If you still haven’t started using it, you may want to download the code now so you can execute as you go.

Data Source Objects

To construct a data-bound page, the first steps are determining the source of the data, the data-manipulation capabilities to give the user, and whether or not the user should be able to update and save the data. These capabilities are provided by data source objects (DSOs).
When designing the data binding architecture for IE 4.0, the design team wanted to ensure that the method for specifying the data on a Web page was as open as possible. The result of this goal was to introduce DSOs for supplying data to the page.

SOs encapsulate four specific functions. First, they provide an open method for transporting data to the client. A DSO is free to use the protocol and transport of its choice to access the data. Similarly, the DSO determines the method for specifying the data it supplies. It can use SQL, URLs, or any other method it chooses to specify the data set.
Since the DSO is responsible for the transport and specification of the data, it must also be responsible for supporting any manipulations to the data. All sorting, filtering, transformation, and user update support is the responsibility of the DSO, not the server. Generally, DSOs expose data manipulations through methods or properties.
The fourth function of a DSO is to expose an object model for script access. DSOs are free to expose properties, methods, events, and script-accessible objects to provide access to and manipulation of the data they supply. Again, the DSO determines the programming model. No specific model is imposed upon it by the architecture.

You’re probably wondering how the DSO exposes the data it supplies to a Web page. This is one area where there is a strict requirement on the DSO: it must provide access to the data through the OLE-DB API. Implementing the OLE-DB API in a DSO is not complicated. DSOs are available written with Java, using JavaBeans, or as ActiveX controls written in Visual Basic® or Visual C++®. A Data Source Object Gallery will be available on the Microsoft Site Builder Web (http://www.microsoft.com/sitebuilder). Check there for DSOs to use as well as the source code for the DSOs. The details of building a DSO are beyond the scope of this article.

Source: Microsoft

Forms

Users can provide feedback or use HTML to access databases through forms. Forms can be constructed from five level 2 HTML tags:

• FORM
• INPUT
• OPTION
• SELECT
• TEXTAREA

They provide a user with the ability to enter information which can then be processed on the server as survey information, search information for a database, information request, etc.

Forms by themselves only allow data entry. They require software commonly referred to as gateways, which receive the data, process it, and return a response to the WWW client. Gateways are custom applications written in an available programming language on the server (such as Perl or C). Some gateways are available on the Internet for Z39.50, WAIS, and mail forwarding. Some authors use Javascript to implement client-side form processing.

XHTML is not very different from the HTML 4.01 standard. So, bringing your code up to the 4.01 standard is a good start. Our complete HTML 4.01 reference can help you with that.

In addition, you should start NOW to write your HTML code in lowercase letters, and NEVER skip ending tags (like </p>).

Happy coding!
The Most Important Differences:

• XHTML elements must be properly nested
• XHTML elements must always be closed
• XHTML elements must be in lowercase
• XHTML documents must have one root element

XHTML Elements Must Be Properly Nested

In HTML, some elements can be improperly nested within each other, like this:

<b><i>This text is bold and italic</b></i>

In XHTML, all elements must be properly nested within each other, like this:

<b><i>This text is bold and italic</i></b>

Note: A common mistake with nested lists, is to forget that the inside list must be within <li> and </li> tags.

This is wrong:

<ul>
<li>Coffee</li>
<li>Tea
<ul>
<li>Black tea</li>
<li>Green tea</li>
</ul>
<li>Milk</li>
</ul>

This is correct:

<ul>
<li>Coffee</li>
<li>Tea
<ul>
<li>Black tea</li>
<li>Green tea</li>
</ul>
</li>
<li>Milk</li>
</ul>

Notice that we have inserted a </li> tag after the </ul> tag in the “correct” code example.

XHTML Elements Must Always Be Closed

Non-empty elements must have an end tag.

This is wrong:

<p>This is a paragraph
<p>This is another paragraph

This is correct:

<p>This is a paragraph</p>
<p>This is another paragraph</p>

Empty Elements Must Also Be Closed

Empty elements must either have an end tag or the start tag must end with />.

This is wrong:

A break: <br>
A horizontal rule: <hr>
An image: <img src=”happy.gif” alt=”Happy face”>

This is correct:

A break: <br />
A horizontal rule: <hr />
An image: <img src=”happy.gif” alt=”Happy face” />

XHTML Elements Must Be In Lower Case

The XHTML specification defines that the tag names and attributes need to be lower case.

This is wrong:

<BODY>
<P>This is a paragraph</P>
</BODY>

This is correct:

<body>
<p>This is a paragraph</p>
</body>

XHTML Documents Must Have One Root Element

All XHTML elements must be nested within the <html> root element. All other elements can have sub (children) elements. Sub elements must be in pairs and correctly nested within their parent element. The basic document structure is:

<html>
<head> … </head>
<body> … </body>
</html>

Source : W3Schools