Blogging Roller

HTML5 Microdata and Schema.org

Dave Johnson — Thu, 9 Feb 2012 08:48:06 +0000

Worth a read and related to my Web Integration Patterns post on Embedded Properties in HTML:

HTML5 Microdata and Schema.org:HTML5 Microdata and Schema.org On June 2, 2011, Bing, Google, and Yahoo! announced the joint effort Schema.org. When the big search engines talk, Web site authors listen. This article is an introduction to Microdata and Schema.org. The first section describes what HTML5, Microdata and Schema.org are, and the problems they have been designed to solve. With this foundation in place section 2 provides a practical tutorial of how to use Microdata and Schema.org using a real life example from the cultural heritage sector. Along the way some tools for implementers will also be introduced. Issues with applying these technologies to cultural heritage materials will crop up along with opportunities to improve the situation.

OSLC Core v2 specification now FINAL

Dave Johnson — Wed, 1 Jun 2011 14:38:13 +0000

I've been working on the OSLC Core specification for about 1.5 years now as workgroup lead, and OSLC fits squarely under the "open web technologies" and Web Integration Patterns topics of this blog, so I'm blogging this happy news.

Here's the announcement From the OSLC Core Workgroup mailing list:

From: Dave Johnson
To: oslc-core (a) open-services.net, community (a) open-services.net
Subject: OSLC Core v2 specification now FINAL

Today [1], I'm very happy to announce that the OSLC Core v2
specification is FINAL.

The OSLC Core v2 specification [2] defines a set of REST and Linked
Data-based patterns, resources and protocols for integration of application 
and product lifecycle resources (ALM and PLM). It's designed to be the
foundation for all other OSLC domain specifications and there are now
three final OSLC specifications that are based on the Core, those
being the OSLC Change Management (CM) [3], OSLC Quality Management
(QM) [4] and OSLC Requirements Management (RM) [5] specs.

I'd like to thank all of the members of the OSLC Core Workgroup and
community for their hard work, critical thinking and ability to work
together in such a productive and pleasant way. Also, special thanks
to those OSLC domain workgroups who rebased their work on the Core and
development teams that provided excellent feedback along the way.

Thanks,
- Dave

--
David M. Johnson
OSLC Core Workgroup Lead
IBM Rational Software

[1] Move to final was proposed last week, along with a small set of
changes which have since been applied to the specification. 
[2] OslcCoreSpecification
[3] CmSpecificationV2
[4] QmSpecificationV2
[5] RmSpecificationV2

I really do have another Web Integration Patterns post on the way shortly, so stay tuned.

WIP: Links

Dave Johnson — Mon, 21 Mar 2011 06:49:23 +0000

This is the first in my series of Web Integration Patterns. Check out the intro at this URL http://rollerweblogger.org/roller/entry/web_integration_patterns

Synopsis

Use links as a way to integrate web sites & applications via navigation and relationships between resources.

Motivations

Provide navigation between integrated web sites & applications
Create meaningful relationships between web resources

Related patterns

Common Navigation
Embedded Properties in HTML
Resource Preview
Delegated Selection & Creation
Linked Data & REST

The web is the web and hypertext is hyper because of links. Links allow for the most deep and also the most shallow forms of integration. Links enable navigation and with some discipline, links can also express relationships between resources. There are a variety of ways to express links; the standard and most popular way is to use HTML, but there are others and I’ll cover them below.

Links enable navigation

With links, you can provide navigation between web applications at the application, or the feature level. One example is providing a link from the blog application of a social software suite to the wiki, forums and other component applications. Another is providing a link from one application to one specific part or feature of another application. This type of linking is easy to implement but fairly shallow. It’s convenience and not much more.

Links can express relationships

What’s more useful and powerful, is using links to create meaningful relationships between the resources provided by web applications. For example, there's obvious value linking a defect in a bug tracking system to the source code changes that fixed the bug in a source code management system. Or, you might link a Requirement resource to the Work-Item resources that implement it. By the way, those example are drawn from the OSLC specs for ALM / PLM integration.

If you want to use links to establish relationships, then you do have to have some discipline about the URLs you offer and the URLs you link to. You have to treat links with the same rigor and respect you’d give primary and foreign keys in a relational database. For example, if you make a resource available in different formats, and each at a different URL, one that ends in “.html” and one with “.xml” and one with “.json” then you’ve got three URLs that refer same resource. In this case, it’s better to use Content Negotiation so you can offer one URL that others can use to link to the resource.

One way to get yourself some link discipline is to adopt Linked Data and the RDF data model, which ”extends the linking structure of the Web to use URIs to name the relationship between things as well as the two ends of the link.” See also the Web Annotations and Linked Data & REST pattern.

Links can be expressed in standard formats

The standard way to represent links on the web is through HTML and in HTML, links are expressed in a variety of ways, via anchor tags, via image tags, the link tag and others. There are other standard ways to express links, but none as popular as HTML.

HTML

In HTML, links can be expressed via the <a> element, for expressing a hyperlink in text, and the <link> element, for expressing a link to a resource associated with the page.

<a> and <link> links can specify not only the URL of the link but also the relationship type of the link, as well as content-type and language for the resource that lies at the other end of the link. For example, a link type of rel=”next” indicates that a link points to the next page in a series of pages, or multi-page article. A link type of rel=”stylesheet” indicates that the link is to style-sheet to be applied to the current page. There are a standard set of link relationship types in the HTML spec. Here's an example from this very blog page, the link to this blogs Atom feed:



<link rel="alternate" type="application/atom+xml" title="Recent Entries (Atom)"     
   href="http://rollerweblogger.org/roller/feed/entries/atom" />

Atom

The Atom Syndication Format defines a <link> element, modeled on the one in HTML. Atom adds a length attribute, the size in bytes of the resource at the other end of the link. Atom defines some new links types, alternate, related, self and enclosure. Atom also allows new links to be added and a Atom link-type registry is maintained at IANA.org. Here’s an example link from the Atom comments feed for this blog:



<link rel="alternate" type="text/html" href=
"http://rollerweblogger.org/roller/entry/apache_roller_5_0_rc3#comment-12941523" />

RDF

Another standard way to express links is RDF, using any of the RDF serializations: RDF/XML, Turtle, N3 and soon, there will be a W3C standard for RDF/JSON. Yes, there will be a standard way to express links in JSON and that's good news. For now, we're stuck with RDF/XML. In RDF/XML a link is expressed via the rdf:resource attribute, so for example a link from a Requirement to the user that created the requirement might look like this:



<dc:creator rdf:resource="https://localhost:9443/user/676" />

RDF (Wikipedia page) goes way beyond the couple dozen link attributes and relationship types provided by HTML and Atom. RDF provides ways to specify property values about any linked resource, and property values of each link. RDF also provides ways to define vocabularies of properties.

Wrapping up

It's time to wrap-up. For better or worse, I’ve written more than I expected to write and I’m nowhere near done with the topic of links. I hope I’ve covered the important parts. Comments are open so please correct me and make suggestions if you got some. This is the first pattern that I’ve written up, so I’m also interested in comments about the format, level of abstraction, value, etc. as well.

Next up: Common Navigation.

re: RDF and OpenSocial

Dave Johnson — Fri, 3 Dec 2010 08:22:48 +0000

This is the closest thing to a blog post that I've written lately, a post to the OpenSocial specification group on aligning OpenSocial with RDF and Linked Data:

This is a topic of interest to me, so I'll try to elaborate.
First, I want to point out that RDF is not a representation, it's a way to model data and it's multiple ways to represent that data (in XML, JSON, etc.). I think the real question is: how do we enable OpenSocial to hook into the RDF-based web of "Linked Data" that is rapidly growing up around scientific data, government open data and the academic world. I'm not going to go into the benefits of Linked Data in this post, but I will disclose that I work for a company that uses RDF as a common data model to enable loosely coupled integration across our web application products (see also Jazz Integration Architecture [1] and OSLC [2]). We'd like to be able to integrate with OpenSocial services in the same ways.

I'll explain the basics of RDF. RDF is way to model web data and ways to represent that data in XML, JSON, Turtle, etc. The RDF data model is simple, we have resources identified by URIs and property values associated with those resources. Resources can have types, each type is identified by a URI. Property types have URIs too. Once you have defined your data model in terms of RDF types and properties, you can represent resources and their properties using RDF representations. There's RDF/XML for XML, there's RDFa for embedding properties in HTML. There's are JSON representations too, but not a standard for JSON yet.

So, to bring OpenSocial in-line with the world of Linked Data, we would define each class of OpenSocial objects as an RDF type, with a URI. We would define each OpenSocial property as an RDF property, with a URI. In some cases, we'll want to use existing properties, like the Dublin Core title, name, etc., and in some cases we'll want to define entirely new types and properties.

As a starting point, I think we would do the following:

* In OpenSocial v2, we would define all OpenSocial objects and properties as RDF types in the OpenSocial Specs. This means simply assigning a URI to every class and every property we define, using standard properties where appropriate and defining new ones as needed. Object and property names would rename the same and we'd have what is essentially an RDF mapping built into the spec. Existing OpenSocial representation formats would stay the same, but we'd add some new RDF representations.

* We'd introduce an optional new OpenSocial spec that services MAY implement: the OpenSocial RDF Specification. The specification would simply require that a service provide RDF representations of it's resources via content-negotiation. The service could offer RDF/XML or HTML with RDFa, JSON/RDF or all of the above.

That's a starting point and I think we could come up with some other ideas if we thought more about use cases. Anybody else interested in aligning the worlds of OpenSocial and Linked Data?

Link: RDF and OpenSocial