The only two patterns you need to know for Linked Data resources, and how we're standardizing them

Body

Patterns

1. Single resources
2. Collections of resources

I don't think it's any secret that "all" Web resources have a certain common set of properties that are of broad interest; that's why we have standards like Dublin Core, whose contents many will recognize (title, description, created date, modified date, etc.) even if people still insist on re-inventing them with each new API.

One of the nice things about Linked Data is that it avoids this re-invention - RDF representations of those resources just use common definitions from places like Dublin Core.  As client code, this means you can consume many different kinds of resources, find these properties, and do at least "simple" things like populate a UI.  All that is a consequence of Linked Data's use of RDF, which gives you contextless property names - in other words, you don't have to know whose implementation of which API you're talking to in order to recognize and process these properties.  If you own client-side code, you get more re-use. 

Single resources

Virtually all resources have these properties (always treat them as optional at the application level, in the sense of "if it's absent, don't go casters-up")

• title
• description
• created and modified timestamps
• type(s)
• identifier

The OSLC Common Properties specification lists a few more, but the ones above are pretty much the bare minimum.  It's no accident that this is the kind of information you need to do much of anything sensible in a UI, even if the sweet spot for RDF is more about programmatic consumption.

Collections of resources

Many resources exist first and foremost as a way to locate (link to) other resources that are related in some way determined by the collection.  Everything from "what servers am I managing" to query results falls into this broad category.  These collections also follow the single-resource pattern above, so they'll typically have all those properties.  In addition, they'll have properties to link to members.

• rdfs:member is the "link to member" property you'll see used in most of our collections today

Some collections might also provide a factory function that knows how to manufacture new resources; most follow the pattern popularized by AtomPub (HTTP Post to create-new).  AtomPub created a problem for itself when it decided to tie itself to XML only, so as the REST/JSON ideas were adopted the "Post to create" idea survived even where other media types or metamodels (like RDF) were used.

The W3C Linked Data Platform

When we started implementing collections in RDF, we were working ahead of where the standards were.  Resisting the tragedy of the commons, we set about to fill that void, informed by IBM's experience (Rational's CLM applications were also using Linked Data extensively).  The (work in progress!) result is the Linked Data Platform being standardized at the W3C.  I'm a editor on that document, and we're getting ready to publish our second (and we very much hope final) Last Call draft.  The next draft will be significantly changed; if you want a preview, here is the editor's draft (this is always the latest; it might take a month before the official LC2 draft arrives that the /ldp link).

In terms of the upcoming draft, most of our collections today correspond to LDP Direct Containers.  This is the variety whose members are all documents on the Web (quite possibly, some visible only on your intranet), and whose link property name can vary ... the latter turns out to be fairly important if you're trying to overlay LDP onto an existing data model.

If there are any business partners interested, "soon" after the LC2 draft the working group will issue a Call for Implementations.  The editor's draft is the right starting point for any such work.