This issue of XML Daily Newslink is sponsored by:
- W3C Proposed Recommendation for 'RDFa in XHTML: Syntax and Processing'
- SmartGrid Domain Experts Workgroup NIST
- Common YANG Data Types for YANG Data Modeling Language
- Google Geocoder Web Service: Overlay Data on Maps Using XSLT, KML, and the Google Maps API
- Business Process Semantics: An Opportunity for Convergence
- OpenSocial Foundation Launches with Google, Yahoo, MySpace
- Jeff Barr Discusses Amazon Web Services
W3C Proposed Recommendation for 'RDFa in XHTML: Syntax and Processing'
Ben Adida, Mark Birbeck (et al., eds), W3C Technical Report
W3C's Semantic Web Deployment Working Group and XHTML2 Working Group have published the Proposed Recommendation for " RDFa in XHTML: Syntax and Processing. A Collection of Attributes and Processing Rules for Extending XHTML to Support RDF." A companion "RDFa Implementation Report" describes implementations of the RDFa Syntax and Processing rules, that is, implementations that are able to parse an XHTML+RDFa document and generate an RDF graph according to the processing rules. The modern Web is made up of an enormous number of documents that have been created using HTML. These documents contain significant amounts of structured data, which is largely unavailable to tools and applications. When publishers can express this data more completely, and when tools can read it, a new world of user functionality becomes available, letting users transfer structured data between applications and web sites, and allowing browsing applications to improve the user experience: an event on a web page can be directly imported into a user's desktop calendar; a license on a document can be detected so that users can be informed of their rights automatically; a photo's creator, camera setting information, resolution, location and topic can be published as easily as the original photo itself, enabling structured search and sharing. RDFa is a specification for attributes to express structured data in any markup language. This document specifies how to use RDFa with XHTML. The rendered, hypertext data of XHTML is reused by the RDFa markup, so that publishers don't need to repeat significant data in the document content. The underlying abstract representation is RDF, which lets publishers build their own vocabulary, extend others, and evolve their vocabulary with maximal interoperability over time. The expressed structure is closely tied to the data, so that rendered data can be copied and pasted along with its relevant structure. The rules for interpreting the data are generic, so that there is no need for different rules for different formats; this allows authors and publishers of data to define their own formats without having to update software, register formats via a central authority, or worry that two formats may interfere with each other. RDFa shares some use cases with microformats. Whereas microformats specify both a syntax for embedding structured data into HTML documents and a vocabulary of specific terms for each microformat, RDFa specifies only a syntax and relies on independent specification of terms (often called vocabularies or taxonomies) by others. RDFa allows terms from multiple independently-developed vocabularies to be freely intermixed and is designed such that the language can be parsed without knowledge of the specific term vocabulary being used. This document is a detailed syntax specification for RDFa, aimed at: (1) those looking to create an RDFa parser, and who therefore need a detailed description of the parsing rules; (2) those looking to recommend the use of RDFa within their organisation, and who would like to create some guidelines for their users; (3) anyone familiar with RDF, and who wants to understand more about what is happening 'under the hood', when an RDFa parser runs.
See also: the RDFa Implementation Report
SmartGrid Domain Experts Workgroup NIST
Toby Considine, AutomatedBuildings.com
This article presents notes of an August 5, 2008 Meeting, taken by Toby Considine (Systems Specialist, Facility Services, University of North Carolina, Chapel Hill): "NIST (National Institute for Standards and Technology) started by making a strong claim for ownership in this area, citing Title XIII, 1305 of EISA 2007. NIST set out an aggressive agenda including a preliminary report at GridWeek 2008 on 9/24 and a NIST workshop on developing standards at Grid Interop in Atlanta November 11-13, 2008. NIST wants to have in place tight working relationships with the target SDOs (Standards Development Organizations) in place before 2009. NIST and the GridWise Architectural Council are working together to direct the standards direction toward e-commerce and interactions with building operations and with the building occupants. The Council identified OASIS as the critical SDO for its e-commerce expertise, a view strongly seconded by the NIST secretary and by the domain leaders. A secondary interest was noted in relationships with the NBIMS (National Building Information Model Standard) and BuildingSmart was identified. NBIMS provides standards for describing building operations and energy models. NIST would like to fast track standardization building services to lay alongside energy models. There was some interest in and discussion of reaching out to FIATECH to accelerate operations / energy use interactions... The goal of the SmartGrid standardization efforts is to design the information exchange and informational interoperability to enable healthy markets to emerge around energy use in buildings. Success was defined as enabling buildings to trade their energy. The group was in violent agreement that we needed to work on business to business interactions, and not on machine to machine interactions. Services inside the building would be coordinated by the business processes of the occupants. Grid messages would go to the business agent of the occupants. Interactions, including pricing and bidding, would be between the grid agents and the building agents..."
Common YANG Data Types for YANG Data Modeling Language
Juergen Schoenwaelder (ed), IETF Internet Draft
Members of the IETF NETCONF Data Modeling Language (NETMOD) Working Group have published an initial -00 Internet Draft for "Common YANG Data Types." Contributors include Andy Bierman, Martin Bjorklund, Balazs Lengyel, David Partain, and Phil Shafer. YANG provides the language and rules for defining such models for use with NETCONF (RFC 4741). YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. This document describes the syntax and semantics of the YANG language, how the data model defined in a YANG module is represented in XML, and how NETCONF operations are being used to manipulate the data. The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. This document introduces a collection of common data types derived from the built-in YANG data types. The definitions are organized in several YANG modules. The "yang-types" module contains generally useful data types. The "inet-types" module contains definitions that are relevant for the Internet protocol suite while the "ieee-types" module contains definitions that are relevant for IEEE 802 protocols. Their derived types are generally designed to be applicable for modeling all areas of management information. Appendix A 'XSD Translations' presents XML Schema (XSD) translations of the types defined in this document; Appendix B 'RelaxNG Translations' provides the RelaxNG translations for Core YANG Derived Types, Internet Specific Derived Types, and IEEE Specific Derived Types.
Google Geocoder Web Service: Overlay Data on Maps Using XSLT, KML, and the Google Maps API
Jake Miles, IBM developerWorks
Google Maps has become the ubiquitous map technology on the Web, allowing users to instantly bring up geographical maps and pan and zoom around them, including 360-degree views of the street at eye-level. Google Earth provides a 3D photographic encyclopedia of the Earth, letting you pan and zoom an image of the Earth at various heights. With the Google Maps API, you can embed Google Maps into your own Web pages. Add KML, an XML language used to describe geographical information such as coordinates on the Earth, and you can overlay your own visual and textual data onto the maps. You can also import KML data into Google Earth, and project your own 3D data onto the Earth as the user pans and zooms. In this two-part article series, you will combine it with the Google Maps API and XSLT to create data overlays for display in Google Maps and Google Earth. You will create an example application for a real-estate brokerage that lets a broker enter listings for apartments through an HTML form, uses Google's Geocoder Web service to translate those addresses into longitudes and latitude, and then creates KML overlays from the database of apartment listings. In Part 1, you build the first half of the application to collect the apartment listing information from the user, uses the Google Geocoder Web service to turn the street address into its geographical coordinates (longitude and latitude), and stores those coordinates in the database along with the address information. In Part 2 of this serial article we use stored procedures to produce XML data from a MySQL query, XSLT to transform that data into KML overlay data, and the Google Maps API to display the KML on a map embedded in the Web site... In the example data for Nine Inch Nails' album "The Slip", rendered using Google Earth and KML, the height of each spike reflects the number of downloads recorded at that location, and was created (one must assume), by creating a line in KML at the download's longitude and latitude, from altitude 0 to an altitude proportionate to the number of downloads at that location. One critical detail missing from this visualization is the ability to map customer addresses, or at least postal codes, to their geographical coordinates on the Earth, because all custom KML data is positioned on the Earth using longitude, latitude and altitude coordinates. To solve this problem, Google recently made available the Google Geocoder Web service, that takes a street address and returns KML data describing the address to whatever accuracy is possible, including its latitude and longitude. Once you have these coordinates you can overlay textual and visual data on 2D maps and the 3D globe as creatively as your imagination allows. [Note: KML is an international standard maintained by the Open Geospatial Consortium (OGC).]
See also: the Google Maps API
Business Process Semantics: An Opportunity for Convergence
Stephen Zisk, DM Review Magazine
Knowledge management professionals help businesses improve performance by formalizing the understanding of what the business is accomplishing, how well it is doing and what is impeding the business both internally and externally. Knowledge management is a wide-ranging discipline, looking at the business in terms of requirements, data collection and improvements. One unifying principle is the recognition that all businesses change and that improvement requires embracing change. This article examines two approaches to improving a business and discusses how these approaches—business process management (BPM) and semantic Web technology—may be used together to improve business agility in the face of change... The focus on the process of a BPMS often puts a prescriptive and sequential spin on data modeling. However, this is somewhat countered by the inclusion of business rules, their focus on policy as well as a descriptive or declarative approach to business or process decisions and the data needed to make them... Semantics is the study of meaning in communication. Semantic data models, or ontologies, are formal models of domains of interest and have been explored for more than 25 years as part of artificial intelligence and knowledge management for computer reasoning, data classification and normalization and linguistic and text analysis. The core standards for the semantic Web, managed as part of the World Wide Web Consortium (W3C) semantic Web activity, include the resource description framework (RDF). The framework defines abstract statements and provides an XML-based implementation language and Web ontology language (OWL), which extends RDF to define ontologies. OWL and RDF implement an object-relational model allowing creation of a directed graph, a network of objects and relationships describing data. This model is potentially richer and more flexible than traditional data models used to implement relational databases. BPMS is a maturing software sector with well-understood benefits and a good choice of software, but with just enough focus on data and information management to execute processes. Bringing semantic Web technology into a BPM practice offers rigorous and explicit data modeling and allows integrated rules engines to reason, classify and improve data quality in the BPMS... Existing standards for BPM and rules are immature and do not play well with the more mature standard set for the semantic Web. Berners-Lee, in his Rule Interchange Format (RIF) announcement referenced previously, said, "A Rule Interchange Format will, for example, help businesses find new customers, doctors validate prescriptions and banks process loan applications." This is the promise of an advanced BPMS, and standards committees could help reduce silo standards. If enlightened vendors can deliver merged BPM and semantic Web capabilities with a strong integrated rules approach, businesses will adopt the solution as their next generation data and process architecture.
See also: Standards for Business Process Modeling
OpenSocial Foundation Launches with Google, Yahoo, MySpace
Clint Bounton, eWEEK
See also: the OpenSocial RESTful API Specification
Jeff Barr Discusses Amazon Web Services
Ryan Slobojan, InfoQueue
In this interview from QCon London 2008, Amazon Web Services (AWS) Evangelist Jeff Barr discusses SimpleDB, S3, EC2, SQS, cloud computing, how the different Amazon services interact within an application, the origins of AWS, SimpleDB and Microsoft SQL Server Data Services, globalization of the AWS cloud, the March AWS outage, SimpleDB Stored Procedures and converting between AMIs and VMWare. Excerpts: "For the last couple of years what we've been doing at Amazon is opening up our own computing infrastructure to outside developers. So the same very reliable, very scalable technologies that we use for our own applications are now available to developers for things like storage and messaging and computing and database storage as well. They are all open and accessible to developers on basically a pay-as-you-go basis... We have SimpleDB for structured storage, we have S3 for more block storage, EC2 is the compute cloud, SQS for messaging. We have the Flexible Payment Service for point-to-point money transfer and DevPay is a way to take other services and put your own business model around those services... There is a common authentication service that goes across all the different services. So once you create your Amazon developer account, you use the same private key, public key mechanism to access those services. The services are running inside the same datacenter so there is no charge for bandwidth between services inside the datacenter. So a good example is if you have data stored in S3, you're going to pull over to EC2 for processing, do all that processing, send it back to S3—that bandwidth back and forth doesn't cost us, so we don't charge developers for that bandwidth. So then a common payment mechanism is another common aspect of the services, and then finally what happens is developers will then put these together... A very common architecture is to use the Simple Queuing Service as the messaging between different parts of a scalable app. So a very common one I talk about all the time is Podango and their podcast processing. So they have a number of different functional units running on different EC2 instances and then each different kind of functional unit, be it a transcoding or assembly or different kinds of processing, each of those is driven by a separate queue and there is one or more EC2 instances pulling off of each queue. If a queue is getting too busy, if it's taking too much time to do work they can simply ramp up the number of EC2s working on a given queue, makes it very easy to scale. They can be functional at a very very low level of processing—if they only have a few podcasts per hour they can process that; if they get thousands or tens of thousands, the queues are going to get a little bit bigger, the system automatically senses how busy the queues are and then scales up in response..."
See also: Amazon Web Services
XML Daily Newslink and Cover Pages sponsored by:
|Sun Microsystems, Inc.||http://sun.com|
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/