Cover Pages: XML Daily Newslink: Thursday, 04 December 2008

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Oracle Corporation http://www.oracle.com

Headlines

W3C OWL Working Group Publishes OWL 2 Web Ontology Language Documents
Super-Styling: Are our Current Page-Breaking Hints Too Low-Level for Acceptable Interoperability?
Presentation: Building Rich Internet Applications in Silverlight 2
Incubator Group Final Report: Elements of an EmotionML 1.0
WOA: Putting the Web Back in Web Services
Update: Cool URIs for the Semantic Web
Building Scalable Web Services

W3C OWL Working Group Publishes OWL 2 Web Ontology Language Documents
Christine Golbreich, Evan K. Wallace (et al., eds), W3C Technical Reports

W3C announced the publication of eleven docments relating to the OWL 2 Web Ontology Language. OWL 2 extends the W3C OWL Web Ontology Language with a small but useful set of features that have been requested by users, for which effective reasoning algorithms are now available, and that OWL tool developers are willing to support. The new features include extra syntactic sugar, additional property and qualified cardinality constructors, extended datatype support, simple metamodeling, and extended annotations. Of the eleven documents, four are First Public Working Drafts, and six are Last Call Working Drafts. (1) The "New Features and Rationale" document is a simple introduction to the new features of the OWL 2 Web Ontology Language, including an explanation of its differences with respect to OWL 1. It presents the requirements that have motivated the design of the main new features, and their rationale from a theoretical and implementation perspective. According to their interests, readers can focus on: an informal description of the new features, requirements, examples, theory or implementation perspectives, or/and links to a sample of use cases. These new features are based on real applications, and user and tool developer experience, much of which was documented and discussed as part of the OWLED Workshop Series. Thus it is intended to supplement the Use Cases and Requirements provided as part of the initial OWL Recommendation (OWL Use Cases and Requirements) and to be an overview of OWL 2 new features. (2) The new "Quick Reference Guide" is intended to provide a quick reference to the OWL 2 language, similar to what was provided in the Language Synopsis section of the OWL Web Ontology Language Overview. Inspiration for this effort includes work by the ebiquity Research Group at the University of Maryland Baltimore County (UMBC) on earlier versions of a Reference Card for the Semantic Web. (3) The new "Manchester Syntax" document provides a user-friendly compact syntax for OWL 2; it is frame-based, as opposed to the axiom-based other syntaxes for OWL 2. The Manchester Syntax is used in the OWL 2 Primer, and this document provides the language used there. It is expected that tools will extend the Manchester Syntax for their own purposes, and tool builders may collaboratively extend the common language. It is already used in Protege 4 and TopBraid composer. (4) the new document "rdf:text: A Datatype for Internationalized Text" was co-developed with the RIF Working Group for use with RDF data. It presents the specification for a primitive datatype representing internationalized text that is used in both the RIF and OWL languages. (5) "RDF-Based Semantics" provides the RDF-compatible model-theoretic semantics for OWL 2, called "OWL 2 Full". The Last Call Working Drafts include: "Structural Specification and Functional-Style Syntax", "Direct Semantics", "Conformance and Test Cases", "Mapping to RDF Graphs", "XML Serialization", "Profiles."

See also: the W3C news item

Super-Styling: Are our Current Page-Breaking Hints Too Low-Level for Acceptable Interoperability?
Rick Jelliffe, O'Reilly Technical

In the past, we could neatly categorize publishing systems into perhaps four big classes: (1) quality or batch typesetting (book typesetting) such as 3B2, JADE or TeX; (2) word processing (WP) such as Word Perfect or AbiWord; (3) desktop publishing (DTP) such as PageMaker; (4) report generators such as Crystal Reports. Recently many products have swapped over into some new arrangement that I haven't been bothered to categorize: for example, Adobe In-Design handles the design-intensive pages that we associate with DTP but allows batch runs, so it can handle many of the report generator and typesetting tasks too. The old categories are not as compelling to the market any more, and so the products are getting more diffuse. One of the big drivers is of course the advent of XML. It profoundly disentangles the input from from the middleware, in the same kind of way that PDF disconnects the output from the middleware. Similarly, the adoption of XML-in-ZIP formats by WP applications also grows their congeniality to uses beyond word processing. I point out these different classes because there is a great difference in the capabilities that each of these kinds of systems support. The one I am particularly interested in is page-breaking behaviour: or, at least, the settings or hints that some software uses to know when a page is full and a new page break needs to be done... Recently I have been considering whether our ideas of page-break styling, derived as they are from the mechanisms of quite ancient WP systems, could be replaced (augmented? superceded?) by some more high level styling concepts that would allow greater mechanism-independence for typeset output. This has been prompted by several jobs over the years and recently. To give the basic idea, I derive three properties which can be applied to any element: [i] Announcement which is the need for some element to be graphically separate from its surroundings. This has two flavours: starting and ending. []ii Cohesiveness is the need for an element to be on the same page, column or line. I'd distinguish three flavours of this, initial cohesiveness (first page, column, line, etc), final cohesiveness, and general cohesiveness. [iii] Relevance is the need for an element to be exactly in sequence. I'd distinguish to flavours, forward and backward, which allow floating scoped to progressively more siblings and ancestors. The idea would be that there is a fairly concrete correspondence between settings in of these properties and the various keep-with-next, widow/orphan, soft/hard page-break etc mechanism of the various typesetting systems. So a document that was specified using these super-styles would be retargetable between typesetting systems that were very different, without raising the bar for vendors too much in terms of their mechanisms...

Presentation: Building Rich Internet Applications in Silverlight 2
James Vastbinder and Mike Taulty, InfoQueue

Silverlight 2 is a cross-platform, cross-browser plug-in and runtime for building rich internet applications. Mike Taulty, of Microsoft, walks through Silverlight basics such as the XAML UI Model and progresses to building applications with both Visual Studio 2008 and Expression Studio as he discusses its programming capabilities. Mike covers the following topics: (1) Silverlight Tooling (2) Declarative XAML (3) Silverlight Application Packaging (4) Core UI and UI Controls Mike finishes the presentation with a uber-demo that uses Sliverlight's network capabilities, Filesystem, LINQ and HTML bridge to demonstrate how Silverlight fits into the .NET Framework. A separate InfoQueue article by Abel Avram (Moonlight 1.0 Beta 1 Available for Download) describes Moonlight: "Moonlight is an open source implementation of Microsoft's Silverlight targeted at Linux and Unix/X11 systems. Moonlight has been developed under the Mono project since September 2007 and is sponsored by Novell. Moonlight 1.0 Beta 1 has been released to the general public. Novell and Mono have announced the release of Moonlight 1.0 Beta 1 available for 32 bit and 64 bit Linux systems. The currently supported operating systems are: SUSE Linux Enterprise Desktop 10, openSUSE 11.0, Ubuntu 8.04, Fedora Core 9 for 32 bit machines, and SUSE Linux Enterprise Desktop 10 and openSUSE 11.0 for 64 bit machines. The recommended browser is Firefox 3 due to its support for windowless operation, a feature commonly used by Silverlight. Moonlight 1.0 is planned to be released into production on January 20th, 2009. It uses Media Pack 1.0 for video/audio playback, Silverlight 2.0's adaptive streaming, and the next features: Silverlight 1.0 compatible engine; Scriptable with the browser JavaScript; C/C++ based, no managed code; Distribution: Linux/x86 and Linux/x86-64; Source code releases for any other operating systems...

Incubator Group Final Report: Elements of an EmotionML 1.0
Paolo Baggia, Felix Burkhardt (et al), W3C Incubator Group Report

W3C announced that members of the Emotion Markup Language Incubator Group have published their final report. As the web is becoming ubiquitous, interactive, and multimodal, technology needs to deal increasingly with human factors, including emotions. The report provides elements for an Emotion Markup Language striking a balance between scientific well-foundedness and practical applicability. The language is conceived as a "plug-in" language suitable for use in three different areas: (1) manual annotation of data; (2) automatic recognition of emotion-related states from user behaviour; and (3) generation of emotion-related system behaviour. The report is the result of one year's work in the Emotion Markup Language Incubator Group, which built on the results of the Emotion Incubator Group. Twenty-one (21) persons participated in the group: 11 delegates from nine W3C member institutions (Chinese Academy of Sciences, Deutsche Telekom, DFKI, Fraunhofer Gesellschaft, IVML-NTUA, Loquendo, MIMOS BHD, Nuance Communications, and SRI International) as well as ten invited experts. This publication is part of the Incubator Activity, a forum where W3C Members can innovate and experiment, and is not on the W3C standards track. The scope of Incubator Groups (XGs) is expected to be new, potentially foundational technologies. This includes ideas for technologies with the potential for broad use to support the infrastructure of the Web. However, these ideas are not ready for Recommendation Track development. For example, they might be innovative and/or highly speculative ideas that may or may not be entirely consistent with the current Web architecture or with other work at W3C and elsewhere; they may address functions for which the design is not yet well-enough developed or for which there are many possible solutions, or functions for which there is not yet sufficient consensus in the community... The Incubator Activity Lead provides oversight, guidance, resolution of issues, and assessment of the proposals and Incubator experiment. The Activity also receives systems and administrative support. Because of the ease of starting an XG, and the breadth of the possible scope of work, it is possible that work within an XG could overlap in functional objective with work underway elsewhere within the W3C or within other organizations. It is desirable to take ideas related to specific technology solutions that are already being worked on elsewhere (within or outside of the W3C) back to the place in which the work is taking place..

See also: the W3C Incubator Activity

WOA: Putting the Web Back in Web Services
Nick Gall, Gartner Blog Network

As my friend and colleague Anthony Bradley just pointed out in his blog, our WOA note has finally been published (subscription required) and it's something that I am very proud of. Not just because my co-authors Anthony, Dan Sholler and I produced a well-crafted piece of research, but more importantly because we built consensus in support of Web-Oriented Architecture across Gartner over the past several years. Because of such consensus, the note can put forward Gartner positions such as: (1) Interfaces based on WS-* specifications should be constrained by WOA, especially the generic interface constraints. (2) More often than not, the WS-* protocol toolkit is unconsciously misused to create needlessly specialized interfaces. (3) Application neutrality should be the principal goal of an interface, and implementation neutrality should be a secondary goal. WOA is an architectural substyle of SOA that integrates systems and users via a web of globally linked hypermedia based on the architecture of the Web. This architecture emphasizes generality of interfaces (UIs and APIs) to achieve global network effects through five fundamental generic interface constraints: [i] Identification of resources; [ii] Manipulation of resources through representations; [iii] Self-descriptive messages; [iv] Hypermedia as the engine of application state; [v] Application neutrality... Those of you familiar with Roy T. Fielding's REST Thesis will no doubt recognize that WOA's five generic interface constraints are an extension of Roy's four uniform interface constraints. The one additional constraint, application neutrality, is implicit in the thesis, but we think it is so fundamentally important that we made it a "first class" constraint. What is application neutrality? "The primary problem with the specifications known as WS-* (such as SOAP, WSDL and UDDI) is that their principal emphasis is on implementation neutrality. All the specifications focus on generalizing away the details of specialized middleware technologies, so that services can be accessed using any one of those technologies. Although this is not an unworthy goal (especially for vendors of specialized middleware technologies), it shifts the focus from the generic interface constraint of application neutrality. Application neutrality should be the principal goal of an interface, because it is precisely this characteristic that enables shareability (a fundamental SOA principle). In other words, interface designers' primary goal should be generic, application-neutral interfaces, which generalize away application-specific details. The key to shared use (reuse) is a generic, application-neutral protocol, such as the Atom Publishing Protocol (APP) or Google's GData Protocol. Conversely, the more application-specific a protocol is, the less shareable it is. With sufficient generality, the most powerful kind of reuse becomes possible: serendipitous reuse..." If you don't like the name WOA, call it REST, or ROA, or Web Architecture, or Fred. The goal is to focus on the key generic interface constraints that unite these concepts, not debate the nuanced differences among them.

Update: Cool URIs for the Semantic Web
Danny Ayers and Max Voelkel (eds), W3C Interest Group Note

W3C announced an update (errata document) for "Cool URIs for the Semantic Web", produced by members of the Semantic Web Education and Outreach (SWEO) Interest Group. The document is a tutorial explaining decisions of the TAG for newcomers to Semantic Web technologies. The Resource Description Framework RDF allows users to describe both Web documents and concepts from the real world—people, organisations, topics, things—in a computer-processable way. Publishing such descriptions on the Web creates the Semantic Web. URIs (Uniform Resource Identifiers) are very important, providing both the core of the framework itself and the link between RDF and the Web. This document presents guidelines for their effective use. It discusses two strategies, called 303 URIs and hash URIs. It gives pointers to several Web sites that use these solutions, and briefly discusses why several other proposals have problems. The document title is inspired by Tim Berners-Lee's article "Cool URIs don't change". It explains two approaches for RDF data hosted on HTTP servers. Intended audiences are Web and ontology developers who have to decide how to model their RDF URIs for use with HTTP. Applications using non-HTTP URIs are not covered. This document is an informative guide covering selected aspects of previously published, detailed technical specifications... Using RDF, the statements can be published on the Web site of the company. Others can read the data and publish their own information, linking to existing resources. This forms a distributed model of the world. It allows the user to pick any application to view and work with the same data, for example to see Alice's published address in your address book. At the same time, Web documents have always been addressed with URIs (in common parlance often referred as Uniform Resource Locators, URLs). This is useful because it means we can easily make RDF statements about Web pages, but also dangerous because we can easily mix up Web pages and the things, or resources, described on the page. So the question is, what URIs should we use in RDF? What URI identifies the company as an organisation, not a [company] Web site? In this document we will answer these questions according to relevant specifications. We explain how to use URIs for things that are not Web pages, such as people, products, places, ideas and concepts such as ontology classes. We give detailed examples as to how the Semantic Web can (and should) be realised as a part of the Web.

See also: 'Cool URIs Don't Change'

Building Scalable Web Services
Tom Killalea, ACM Queue

In the past 10 years the barriers to entry to building large, dynamic Web services have fallen dramatically. Three significant developments have contributed in different ways to this lowering of the barriers: the trend toward SOA (service-oriented architecture), the emergence of cloud computing infrastructure services, and the availability of Web application frameworks such as ASP.NET, Django, Rails, and Spring. These developments greatly facilitate modularity and better separation of concerns. They also bring into focus a new separation of responsibilities. It's important to build only that which only you can build, relying on other people's work or services where possible. Time and resources spent building or customizing a Web application framework or building an infrastructure could be better spent improving the business logic. Everyone needs a framework and infrastructure, but they provide little incremental customer value, so time spent building them is time spent on undifferentiated heavy lifting... One of the hardest problems in the operation of a large Web service is figuring out how to implement a high-fidelity test environment. There's no magic solution, but here again we've found that the problem becomes more tractable by using virtualized resources in our compute cloud. We can achieve a higher degree of fidelity (by running the same system images) and isolation, have greater agility in how we ramp tests up and down, capture results and problems for later analysis, and use resources more efficiently... Craig Russell of Sun Microsystems recently discussed ORM (object-relational mapping); ORM is gaining widespread adoption and bringing scalability considerations. With ORM, data stored in the persistence tier is represented to the application as objects in the native object programming language, thus abstracting the persistence implementation details and facilitating better separation of concerns. An inevitable side effect of using ORM is a lack of transparency with respect to the scalability and performance implications of how queries are ultimately constructed, how much data is retrieved, and at what cost...Practitioners responsible for building scalable Web services have challenges, expectations, and available technologies that have evolved considerably in just a few years. While there is a lot more to a modern Web service than was previously the case, much less of it needs to be built from the ground up...


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors