Re: [rest-discuss] Re: Gartner note on WOA (Web-Oriented Architecture) just published
- Reality check re the REA model: I was one of the people who tried to
define that as a standard format at least for B2B interactions.
I worked on this issue with ebXML, UN/CEFACT and ISO. To some extent,
REA is incorporated in the "standards" of each of those organizations.
Explicitly so for ISO:
ebXML and UN/CEFACT also tried to "standardize" an application
protocol for exchanging business messages using a somewhat-REA-based
The reason I put quotes around "standardize" is that all three of
those groups claimed to provide "standards", all three coming from the
same background sources (EDI and REA), and all three are slightly
Likewise OASIS Universal Business Language (UBL)
spun off from ebXML, and claims to provide yet another "standard" B2B
vocabulary, derived mostly from X12 and EDIFACT EDI without any REA
And then there's OAG http://www.openapplications.org/ which also
claims to provide "standard" business document formats.
And some large supply chain heads use their own proprietary vocabularies.
And the old EDI formats - ANSII X12 and UN EDIFACT - are probably
still used more than any of the above.
- On Wed, Dec 3, 2008 at 3:19 PM, Subbu Allamaraju <subbu@...> wrote:
> Hi Nick,
> Thanks for elaborating.
>> Every industry has myriad master/reference data standards that are
>> "application neutral" aka "application generic". Contrast this with
>> enterprises or applications that use "application specific" product
>> identifiers, country identifiers, disease identifiers, business identifiers.
> There are two things here.
> One is an identifier a la atom:id, whose purpose is to uniquely identify the resource and remain the same. Unlike URIs, this ID is supposed to remain unchanged for the lifetime of the resource. On a related note, I think that every representation (whether using Atom or not) should include an "id" preferably encoded as a URN.
> The second one is how such an identifier (if at all) is encoded into a URI.
> In general, both are opaque to the client.
> AFAIU, your description of "generic identifier" should be applied to the former and let other considerations influence the URI design.
I understand your concerns about URIs changing, but I'm an adherent to the "Cool URIs don't change" school (http://www.w3.org/TR/webarch/#URI-persistence and http://www.w3.org/Provider/Style/URI ). So ultimately, I'd prefer to see all identifiers as URLs (not just URIs) and have such URLs be permanent. However, I'm practical as well. And if someone feels that a different style of URI would be easier to make permanent, then at least that's a step in the right direction.Here's a great example of "generic identifiers" that I just stumbled across. The BBC entered into a licensing agreement with MusicBrainz to reuse the latter's ID's for music et al. Read more about it here: