HTML5 - its support in Dreamweaver CS5, Internet Explorer 9 and elsewhere

With HTML5, an open Web standard, the browser becomes a first class RIA citizen.

HTML5 is being developed as the next major revision of HTML (HyperText Markup Language), the core markup language of the World Wide Web. HTML5 is the proposed next standard for HTML 4.01, XHTML 1.0 and DOM Level 2 HTML. It aims to reduce the need for proprietary plug-in-based rich internet application (RIA) technologies such as Adobe Flash and Microsoft Silverlight.

The HTML5 video tag is a markup language tag, introduced in the HTML5 draft specification, that adds support for embedding video in an HTML page.

The Adobe Flash Player has been and continues to be widely used to embed video on web sites such as YouTube, since the majority of web browsers have Adobe's Flash Player installed (with controversial exceptions such as the browser on the Apple iPhone and iPad). Now, however, HTML5 video is intended by its creators to become the new standard way to show video online, but has been hampered by lack of agreement as to which video formats should be supported in the video tag.

Rather than relying on the browser plug-in Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards. Apple’s mobile devices now ship with high performance, low power implementations of these open standards.

Not to be left out, Adobe has recently added HTML5 support to Dreamweaver CS5. This move should not be viewed only in light of the company's war of words with Apple regarding Flash, but in the other reality that HTML5 is reaching critical mass as evidenced by long-time holdout Microsoft adding HTML5 support to Internet Explorer 9 and a slew of HTML5 books being published by leading houses this summer. I've pictured the covers of a few of them at the end of this post.

These developments come despite the fact that HTML5 is still a work in progress. Even so, HTML5 in Dreamweaver CS5 makes for a mighty application development tool, as shown in the video http://www.youtube.com/watch?v=OEXrd8CR5AY

The HTML5 compatibility pack for Dreamweaver CS5 lets you author CSS3 and HTML5 compatible Web pages for modern browsers. And, of course, it supports the audio and video tags.

Note: The HTML5 extension will work only with Dreamweaver CS5 and not with any of the previous versions.

For more on this new Dreamweaver HTML5 support, check out labs.adobe.com and the following videos:

HTML5 Fundamentals with Dreamweaver CS5 - Semantic Structural Tags - Part 1

HTML5 Fundamentals with Dreamweaver CS5 - Semantic Structural Tags - Part 2

Readers of this blog who are interested in the Semantic Web may find the Part 2 video of particular interest.

HTML5 Fundamentals with Dreamweaver CS5 - Using the Video Tag

Finally, Microsoft will support HTML5 and CSS3 in Internet Explorer 9.0. A developer preview of their next browser can be downloaded from

http://ie.microsoft.com/testdrive/

and click here for a discussion of I.E. 9's support for video content.

Note: There has been a lot of interest and debate about HTML5 and its support for video tags. This release of Internet Explorer provides such support, with tags available for H.264/MPEG4 and MP3/AAC codecs, leaving out support for the open source Ogg Vorbis and Ogg Theora video codecs.

A final note: HTML5 is not likely to displace Adobe Flash videos any time soon. As evidence of this, consider the latest news from Dell: Dell Inc. yesterday unveiled plans for a computer tablet based on Google Inc.’s Android operating system.

Called Streak, the tablet will have a 5-inch screen, Wi-Fi, Bluetooth, and work on a 3G network. Users can download music; interact with social-networking sites; send e-mail, text and instant messages; and make phone calls. It has turn-by-turn navigation with Google Maps, a 5-megapixel camera with flash, and a removable battery.

Streak will have 2 gigabytes of internal storage. Memory can be expanded up to 32 gigabytes allowing it to store as many as 42 movies or 16,000 songs.

Later in the year, the tablet will support Adobe Flash 10.1 — something Apple Inc.’s iPhone, iPad, and iPod Touch devices do not. Flash is widely used for online video.

The Streak is designed to be larger than a smartphone but more portable than a laptop. It is 6 inches wide, nearly 3 inches high, and half an inch thick.

Does the Semantic Web need Ontologies?

The answer to the question "Does the Semantic Web need Ontologies?" is "yes" according to most but "no" according to some. For a discussion of this question, click here for the view of one individual who is convinced that ontologies are a luxury, not a necessity, plus the comments of others.

Probabilistic Reasoning for OWL DL Ontologies -- Reasoning about Uncertain Domain Knowledge

Pronto is an extension of Pellet that enables probabilistic knowledge representation and reasoning in OWL ontologies. Pronto is distributed as a Java library equipped with a command line tool for demonstrating its basic capabilities. (There is no 1.0 release!) The figure below outlines the relationships among Pronto, an OWL DL Ontology, and the editor that might have created the ontology. Pellet supports reasoning with the full expressivity of OWL-DL (SHOIN(D) in Description Logic jargon) and has been extended to support the forthcoming OWL 2 specification (SROIQ(D)).



Pronto offers core OWL reasoning services for knowledge bases containing uncertain knowledge; that is, it processes statements like “Bird is a subclass-of Flying Object with probability greater than 90%” or “Tweety is-a Flying Object with probability less than 5%”. The use cases for Pronto include ontology and data alignment, as well as reasoning about uncertain domain knowledge generally; for example, risk factors associated with breast cancer.

Pronto adds the following capabilities to Pellet:

* Adding probabilistic statements to an ontology (using OWL's annotation properties)

* Inferring new probabilistic statements from a probabilistic ontology

* Explaining results of probabilistic reasoning

Pronto depends on Pellet, which is included in the Pronto release package. It also relies on Ops Research's OR-Objects package, which needs to be downloaded separately.

To download Pronto, click here.

To download OR-Objects, click here.

The features of Pronto (in addition to the features of Pellet) are outlined in the file basic.pdf, located in the /doc directory of the Pronto download.

If you are interested in a rigorous description of the approach taken by Pronto, read the paper by Thomas Lukasiewicz “Probabilistic Description Logics for the Semantic Web,” which is cited under Resources in basic.pdf.

For further reading on Probabilistic Reasoning, click

http://clarkparsia.com/weblog/2007/09/27/introducing-pronto/

http://klinov.blogspot.com/2007_11_01_archive.html

http://clarkparsia.com/weblog/2007/10/02/using-pronto/


For further reading on Pellet features, click

http://clarkparsia.com/pellet/features

An upcoming post will discuss ontologies that use fuzzy logic.

From Star Schema Ontologies Stored in an RDBMS (e.g., i2b2) to Other Ontology Stores and The Semantic Web

Recent posts here have discussed ontologies saved in relational databases (see, for example, my September 11 and 24 posts); while other posts have been about different kinds of ontology stores and the Semantic Web (see, for example, my September 27 and 6 as well as my October 11 posts). If one reads only this blog, one might think that there is no work to exploit the advantages of both approaches in a single system afoot. But, there are. A number of investigators are looking into applications that support connections to both a variety of RDBMS schemas and other forms of ontology management.

What if i2b2 built Semantic Web graphs instead of relational stores? What if it had an OWL-defined Ontology, instead of a relational-schema? Click here.

Semantic Web will be part of i2b2 and will allow it to correlate unique variable names across consortium sites (e.g., white, Caucasian) and for information retrieval. Click here

From Stanford ( Russ Altman et al ) on the west coast to Harvard ( Isaac Kohane et al ) on the east coast in the U.S. Click here.

Ontology Systems. Click here.

i2b2. Click here.

{ click the figure above for a larger view }

Mapping Ontologies - Tools, a Suite, and an Application

Before continuing, I want to devote a little space to fleshing out the subject of Mapping Ontologies, which I have alluded to in a couple of earlier posts. Mapping is a process in which we first try to find similarity between individual elements of two ontologies. We compare the elements on the basis of their names and attributes.

Using Protégé

Note: Protégé (see my August 24 post below) is probably the most popular ontology editor available.

Click here.

Using NeOn Toolkit

Note: The Watson plug-in to the NeOn Toolkit (see my September 27 post below) allows the user to select entities of the currently edited ontology and to automatically trigger queries to a remote ontology.

Click here.

A proposed Web app that addresses a real-world situation with the help of ontology mapping, probabilities, and Jena - a Semantic Web framework for Java.

When incorporating data semantics into the searching process, the correctness of searching can depend directly on mapping results.

Keywords: Protégé, OWL, Jena, Probability

Click here.

A Comprehensive Suite of Tools

A presentation by the former lead developer of Protégé-OWL

Click here.

Uncertain Knowledge, Ontologies, and Reasoners – A Discussion of Semantic Ambiguity in the Presence of Statistical Uncertainty

Before continuing with uncertain domain knowledge, the subject of this and future posts, I’d like to give an example. I’ll introduce a scenario in which both semantic ambiguity (refer to my prior post) and statistical uncertainty (refer to the tutorials in the right-hand column of this blog) are present.

One of the limitations of most current description logic (DL) reasoners (refer to my August 6 & 24 posts below) is the inability to handle uncertain knowledge. It is a serious obstacle to the expansion of the Semantic Web, to name just one technology, because many domains of human interest contains knowledge that cannot be represented with absolute certainty. One example of an uncertain domain is medicine, in particular, disease diagnosis. Symptoms, causes and consequences of many diseases are uncertain which complicates conceptualization of such domains in formal ontologies and thus restricts machine understanding.

The next two figures, rendered without further explanation, illustrate that the difficulties introduced by semantic ambiguity of a deterministic kind can be made even more difficult when there is a need to consider statistical uncertainty at the same time. This might be the case when a patient is seen by one doctor and then asks a second doctor for his or her opinion.

However, these days, a good deal of technology is often employed by doctors before they speak to patients and to each other.

{ click on the images above for larger views }

To be continued . . .

Functional Design of an Ontology --- Relationship of the i2b2 ontology to star schema

Recent posts to this blog have discussed ontologies and description logics . As mentioned earlier, the OWL-DL and OWL-Lite sub-languages of the W3C-endorsed Web Ontology Language (OWL) are based on a description logic. A tool for editing and creating ontologies, Protégé, was also described.

In the present post, I’d like to describe the functional design of the ontology used by i2b2, a collection of open-source software tools for the collection and management of project-related clinical research data. That is, this post will present an introduction to what’s under the hood.

Data storage

i2b2 data is stored in a relational database, usually either Oracle or SQL Server and always in a star schema format, a design proposed initially by Ralph Kimball in the 1980s. It is named this because of the appearance of the final database schema diagram that looks like a star (see figure below).

Notes: Ralph Kimball and I were formerly regular contributors to now-defunct DBMS Magazine. A brief introduction to the star schema format is given in the OLAP section of my article Using Neural Networks and OLAP Tools to Make Business Decisions. (See the bibliography at the bottom of this blog)

{click on the images above for larger views}

A star schema contains one fact and many dimension tables. The fact table contains the quantitative or factual data, while the dimension tables contain descriptors that further characterize the facts.

Facts are defined by concept codes and the hierarchical structure of these codes together with their descriptive terms and some other information forms the i2b2 ontology (also called metadata).

i2b2 ontology data may consist of one or many tables. If there is one table, it will contain all the possible data types or categories. The other option is to have one table for each data type. Examples of data types are: diagnoses, procedures, demographics, lab tests, encounters (visits or observations), providers, health history, transfusion data, microbiology data and various types of genetics data. All metadata tables must have the same basic structure.

The structure of the metadata is integral to the visualization of concepts in the i2b2 tools, as well as for querying the data.

In healthcare, a logical fact is an observation on a patient. It is important to note that an observation may not represent the onset or date of the condition or event being described, but instead is simply a recording or a notation of something. For example, the observation of ‘diabetes’ recorded in the database as a ‘fact’ at a particular time does not mean that the condition of diabetes began exactly at that time, only that a diagnosis was recorded at that time (there may be many diagnoses of diabetes for this patient over time).

The fact table contains the basic attributes about the observation, such as the patient and provider numbers, a concept code for the concept observed, a start and end date, and other parameters. In i2b2, as shown in the figure above, the fact table is called observation_fact.

Dimension tables contain further descriptive and analytical information about attributes in the fact table. A dimension table may contain information about how certain data is organized, such as a hierarchy that can be used to categorize or summarize the data. In the i2b2 Data Mart, there are four dimension tables that provide additional information about fields in the fact table: patient_dimension, concept_dimension, visit_dimension, and provider_dimension.

Scalability

Once a database grows to over 10 million items, the advantages of a star schema can start to take hold. The first consideration is the speed and integrity of the queries. When one exceeds 0.5 billion rows in a database, it becomes important to have the data expressed in very large indexes. Very large indexes are only possible with very large tables. If one has several hundred or thousand tables in a database (easily attained in large transaction systems), one will have at least one index on each table resulting in several hundred or thousand small indexes. Joins between 100‐1000 indexes for each query will result in slow performance (hours), while joins between 3‐4 indexes, even representing 100’s of millions of rows, will be fast (seconds). Furthermore, the integrity of queries in a transactional database is also compromised because queries can often be answered through several paths in a circular manner.

The second consideration is the need for a large analytic database to constantly absorb new data. The database schema does not change as new data sources are added. New data will result in additional rows added to the fact, patient, and visit tables. New concepts and observers will result in new rows added to the concept and provider tables. But new columns and tables do not need to be added for each new data source. This is very useful in large projects where there are many tools depending upon a specific database schema. A strategy where the database grows by adding rows for new data rather than adding new tables and columns allows tools developed to work with one kind of data to also work with a new source of data.

The third advantage of the star schema is the ability to manage the metadata of a large analytic database. Metadata is used to perform queries, and if it is incorrect a query will be profoundly affected. For example, if one wanted to find all the patients with diabetes, but left out one of the codes used to represent diabetes in a database, none of those orphaned patients would be counted. The detection of orphaned concepts is easily achieved in the star schema by, for example, joining the fact table to the concept and provider tables and reporting those fact table concepts and providers left out by the join.

A sample ontology query for diagnosis

To find all the patients that were diagnosed with migraines, use this query:

Select distinct (patient_num)
From observation_fact
Where concept_cd in
(select concept_cd
from concept_dimension
where concept_path like '%Neurologic Disorders (320-389)\(346) Migraine\%')

Note: The material in this post has been taken largely from the following i2b2 pages, which should be consulted for further details:

https://www.i2b2.org/software/projects/ontologymgmt/Ontology_Design_Doc_13.pdf

https://www.i2b2.org/software/projects/workbench/i2b2Workbench_Description.pdf

https://www.i2b2.org/software/projects/datarepo/CRC_Design_Doc_13.pdf

Semantic Web Technologies: Ontologies, Agents, Web Services

Here's a Web app developed at Stanford University some time ago. It's made up of a single ontology with entries for foods and wines, an ontology agent that returns text from this ontology and a portal that manipulates the text returned by the agent.

http://onto.stanford.edu:8080/wino/index.jsp

The ontology underlying the agent used here contains hierarchies and descriptions of food and wine categories, along with restrictions on how particular instances might be paired together.

For readers wanting an easy-to-read discussion on what exactly an agent is and how it works with ontologies, see

http://www.nature.com/nature/webmatters/agents/agents.html

The next three figures are of screen shots taken from this Web app, which doesn't always employ state-of-the-art technologies like OWL (discussed in earlier posts) under the hood; but, this app provides a simple example of the most basic building blocks that are found in many of today's Semantic Web apps (also discussed in earlier posts).



Figure I - The home page




Figure II - After clicking on the "Roast Duck" link




Figure III - After clicking on the "Web Inventory Search" link

The ontology defines the concept of a wine. According to the specification, a wine is a potable liquid produced by at least one maker of type winery, and is made from at least one type of grape (such grapes are restricted to wine grapes elsewhere in the ontology.)

The declaration additionally stipulates that a wine comes from a region that is wine-producing and, most importantly to the agent, that a wine has four properties: color, sugar, body, and flavor.

The concept of a meal course underlies pairing of a food with a wine. Each course is a consumable thing comprising at least one food and at least one drink, the latter of which is stipulated to be a wine.

When the user selects a type of course, or an individual food that gets mapped to a type of course, the agent will consult that course definition for restrictions on the constituent food or wine. All such course types map back to this concept, like objects to their superclasses in object-oriented programming.

Suppose the user has selected pasta with fra diavolo, or perhaps pasta with spicy red sauce directly. The concept of such a food is defined elsewhere in the ontology. Furthermore, such courses must be a subclass of those with specific restrictions on the properties of their wines.

One wine that matches the above restrictions is the Pauillac. This individual wine is simply defined as a Pauillac whose maker is Chateau Lafite Rothschild. Together with other statements in the ontology, this allows the reasoner (discussed in an earlier post) to deduce many additional facts: that this a Medoc wine from Bordeaux, in France, and that it is red, to name a few.

The concept of a Pauillac specifies that all such wines feature full bodies and strong flavors and are made entirely from cabernet sauvignon grapes. Further, Pauillacs are a particular subset of Medocs, distinguished by their origin in the Pauillac region. It is through this additional subclass relationship that Pauillac are defined elsewhere as red and dry.

Following the above example through the ontology reveals a straightforward logical path for pairing the Pauillac with the selected course. Because these items were specified in a standardized, machine-readable format, it is an equally straightforward task for any compliant automated reasoner.

Why use an ontology?

The functionality provided by the wine agent is not unlike that which could be provided by a simple look-up table. Indeed, food/wine pairings are traditionally published in some form of tabular chart where marks appear at the intersections of columns and rows representing compatible varieties of food and wine. The wine agent demonstrates that at least this simple task can be accomplished within semantic markup technology, but what about more complicated applications like, for example, those required by electronic health rcords (EHR)? For now, I'll postpone any discussion of EHR and stick with this food-wine pairing app.

Suppose that if not the entire web, then at least some number of cooperating parties were using semantic markup to participate in this project. Rather than the traditional approach of trying to build an enormous database of foods and wines, then, the definitions would be distributed across the participating parties. A restaurant or retailer offering an on-line menu could mark each food item with standardized machine-readable definitions. Similarly, then, a wine retailer could mark its wines according to the definitions exemplified above.

Such markings would benefit from well-known advantages of ontologies. For instance, through the subclassing, adding a new Pauillac to the inventory would not require wine.com (the source of the GUI shown in Figure III) to mark all of the wine's properties; it would just be another Pauillac as specified in the example, plus any differentiating features. But more importantly in terms of software agents, all the markings would be machine readable, and could be handled by systems from any organization.

Rather than relying on a human user to select a food or food type, the agent could crawl the web for foods marked within the wines namespace and pre-compile suitable pairings. This is where Web services (discussed in earlier posts) come in.

Footnote

The notion of agent-based computing has been adopted enthusiastically in the financial trading community, where autonomous market trading agents have been said to outperform human commodity traders by 7%.

Machines can monitor stock market movements much more quickly than humans, and if you can encode the kinds of rules that you want, then it is not unreasonable to imagine that computational traders will be able to outperform humans.

I commented on high-speed trading in my August 3 post.

Electronic Health Records (EHR) – Semantic Interoperability – Part 2

Before discussing the connection(s) between electronic health records (EHR) and semantic interoperability directly, I’d like to spend a little time talking about Semantic Web interoperability (not necessarily the same thing as the interoperability of present and future EHS systems).

In general, semantics is the study of meaning. Semantic Web (also called Web 3.0) technologies help separate meanings from data, document content, or application code, using technologies based on open standards. If a computer understands the semantics of a document, it doesn't just interpret the series of characters that make up that document: it understands the document's meaning. See my July 20 post for a brief introduction to this material.



Benefits of the Semantic Web to the World Wide Web

The World Wide Web is the biggest repository of information ever created, with growing contents in various languages and fields of knowledge. Search engines might help you find content containing specific words, but that content might not be exactly what you want. What is lacking? The search is based on the contents of pages and not the semantic meaning of the page's contents or information about the page.

Once the Semantic Web exists, it can provide the ability to tag all content on the Web, describe what each piece of information is about and give semantic meaning to the content item. Thus, search engines become more effective than they are now, and users can find the precise information they are hunting. Organizations that provide various services can tag those services with meaning (service-oriented architectures -- SOA -- are discussed in my June 20 post and mentioned again below, this time in the context of semantics); using Web-based software agents, you can dynamically find these services on the fly and use them to your benefit or in collaboration with other services (See http://www.oracle.com/technology/pub/articles/matjaz_bpel1.html for a discussion of the orchestration and choreography of Web services).

Ontologies

The use of words to refer to concepts (the meanings of the words used) is very sensitive to the context and the purpose of these words.

An ontology is a formal representation of a set of concepts within a domain and the relationships between those concepts. It may be used to reason about the properties of that domain, and may be used to define the domain. The word “reason” is an important part of this story and will come up again in a later post, when I talk about Protégé, a free, open source ontology editor and knowledge-base framework.

A domain ontology (or domain-specific ontology) models a specific domain, or part of the world (e.g., healthcare, banking or politics). It represents the particular meanings of terms as they apply to that domain. For example the word card has many different meanings. An ontology about the domain of poker would model the "playing card" meaning of the word, while an ontology about the domain of computer hardware would model the "video card" meaning.

For each domain of human knowledge, an ontology must be constructed, partly by hand and partly with the aid of dialog-driven ontology construction tools (to be discussed in an upcoming post).

Ontologies are not knowledge nor are they information. They are meta-information. In other words, ontologies are information about information. In the context of the Semantic Web, they encode, using an ontology language (to be discussed in an upcoming post), the relationships between the various terms within the information. Those relationships, which may be thought of as the axioms (basic assumptions), together with the rules governing the inference process, both enable as well as constrain the interpretation (and well-formed use) of those terms by the Info Agents (to be discussed in an upcoming post) to reason new conclusions based on existing information, i.e. to think. In other words, theorems (formal deductive propositions that are provable based on the axioms and the rules of inference) may be generated by the software, thus allowing formal deductive reasoning at the machine level. And given that an ontology, as described here, is a statement of Logic Theory, two or more independent Info Agents processing the same domain-specific ontology will be able to collaborate and deduce an answer to a query, without being driven by the same software.

When an organization adapts an ontology-driven approach, it can capture and represent its total knowledge in a language-neutral form and deploy the knowledge in a central repository that provides the same semantic meaning across applications.

Semantics are the future of service-oriented integration

To properly model and manage a service-oriented architecture (SOA), enterprise architects must maintain active representations of the services available to the enterprise. Specifically, to discover and organize their services, the architects must use best practices that model and assemble services using metadata, encapsulate business logic in metadata for dynamic binding, and manage with metadata. Ontologies provide a very powerful and flexible way to aggregate, visualize, and normalize this service metadata layer.

Note: When delivering services as part of a service inventory, there is a constant risk that services will be created with overlapping functional boundaries, making it difficult to enable wide-spread reuse. Normalization addresses this problem. When services are delivered with complementary and well-aligned boundaries, normalization across the inventory is attained. Note also how the quantity of required services is reduced.

Semantic technologies provide an abstraction layer above existing IT technologies, one that enables the bridging and interconnection of data, content, and processes across business and IT silos.

For advanced IT readers

For a rather technical discussions of this topic, see the video Artificial Neural Network based Techniques for Semantic Data Interoperability below and parts of my article Using Neural Networks and OLAP Tools to Make Business Decisions to which there is a link in the bibliography at the very bottom of this blog.



To be continued …