[ckan-discuss] Harvesting Dublin Core documents

[John Bywater]

William Waites wrote:
> * [2010-11-24 16:53:56 +0000] John Bywater <john.bywater at appropriatesoftware.net> écrit:
> 
> ] It could be used on either side of the API. CKAN's harvester talks to 
> ] the catalogue model via the presentation layer, CKAN's presentation 
> ] layer has CKAN Package dicts, and the CKAN API just exposes that 
> ] presentation model on the system boundary.
> 
> It is very good to have a system boundary like that. Tools such as
> agents that check links or accuracy of information reported in package
> metadata or harvesting jobs or ckanjson -> fooformat translators
> should not worry about anything that is behind that boundary. (I'm not
> sure what you mean by "presentation layer" I'm familiar with that term
> from the OSI protocol stack but you seem to be using it in a
> different way).
> 

Oh, by presentation layer, I'm refer to the n-tiered application 
architecture. To locate this in the OSI protocol stack, we're on layer 
7, the application layer.

With an application, commonly there are three distinct layers: firstly 
an isolated domain model layer; secondly a persistence layer which 
reflects the domain model into a database; thirdly a presentation layer 
which reflects the domain model into an interface.

It's an adequate model, and by far the most common. Some (much less 
common) considerations dispense with the vertical line, as Alistair 
Cockburn does with his hexagonal architecture. They claim that since 
software does not really know which way is 'up', it doesn't make sense 
to privilege one object collaboration over another.

http://xunitpatterns.com/Hexagonal%20Architecture.html
http://alistair.cockburn.us/Hexagonal+architecture

Having said that, Grady Booch declares the history of software 
engineering to be the history of increasing layers of abstraction. Also 
domain driven design refers to an isolated domain model layer. Layers do 
have direction (in a stratigraphic sense).


> By treating this system boundary as fixed and not being tempted to
> reach behind it it means that, e.g. Volker's project of making a
> geocouch service that mimics the API will be able to be used by the
> same tools. It means that different front-ends and visualisations will
> be able to work with whichever back-end and be developed
> independently. This way we could encourage a whole ecosystem of tools,
> ckan having defined the protocol.
> 

That sounds wonderful!


> Or it is an iron-clad boundary behind which any refactoring is free to
> happen...
> 

I'm not sure what is meant by an "iron-clad boundary". By definition, 
each version of the API should be always be backwards compatible, 
because the architecture is for any backwards incompatibilities to 
trigger a new API version.

Since refactoring is properly about improving a design without changing 
its external behaviour, refactoring shouldn't constitute any 
destabilisation of API interoperability.

(I'm aware that when people say "refactor" they often do not mean the 
external behaviour will be unchanged. So they should say "rework", or 
something like that.)

Anyway, back to the ecosystem of tools: is Volker on this list? We can 
extract from the de facto CKAN API a hard core of the most useful 
aspects, and then start with the package registry. Then we could invest 
in a community test suite, which would be a really good way of 
engineering the interoperability you're looking for.

J.


> Cheers,
> -w