On Tue, Feb 19, 2013 at 04:53:59PM +0100, Antoine Isaac wrote:
> Thanks for starting this over. However, while I'm eager to put aside complex
> acronyms/notions to make progress, I'm quite reluctant to jump to "community
> profile". The notion of "application" is really important, as it provides the
> requirements that at the end of the day will scope the product. In many
> cases, I agree that community will provide useful context. But it can also be
> utterly vague and provide many opportunities for procrastination. Let's not
> forget we are engineering artifacts that serve concrete application purposes,
> not a "community" in general.
> Is "application profile" so unpopular? I have the feeling it is more
> "abstract model" that people fight with...
What we have called "application profiles" over the years cover document styles
and granularity ranging from simple lists of properties to developer-ready
specs. I have heard complaints from people who find "application" to be
evocative, but unhelpfully vague and ambiguous. Ultimately, I think people
approach the notion of application profiles with different requirements and
expectations -- some closer to those simple documentation of consensus, some
closer to well-engineered artifacts that serve concrete application purposes.
Back in 2006, Dan Brickley proposed [1]:
In the simplest case, a DC Application Profile characterises the shared
description interests of some community of interest. This can be achieved
using natural language and other human-oriented materials (eg. case
studies, online discussion fora, etc). In addition to human-centric
documentation, Application Profiles can often usefully be described with
various machine-readable techniques. The applicability of such techniques
will vary depending on the degree of consensus and commonality of interest
in the relevant community.
To me, "Application Profile" seems to be stuck in the middle between the two
extremes. Maybe that's a good place to be, but maybe it is unhelpful because
it encourages us to seek a "one-size-fits-all" approach to specifying profiles,
where it might be more helpful to distinguish, say, Community Profiles
(human-oriented expressions of community consensus) from, say, Serialization
Profiles, or even DCAM Description Set Profiles (developer-oriented specs).
> Plus we'd have to re-work all the DCMI documents...
Well that's certainly a valid point! :-)
> By the way, we had stopped the discussions last year at the time I was about
> to work on actions I had had for a while. Here is a link to the Europeana
> Data Model, which I regard to be an application profile of DC, OAI-ORE, SKOS
> and a couple of others:
> http://pro.europeana.eu/edm-documentations
Hmm - "Not Found. The requested resource was not found.
http://pro.europeana.eu/web/guest/edm-documentations"
But I'm guessing this is the level where we should be focusing right now.
> There are many documents here that we could use to test our various template
> ideas. Note that most of these are not strictly formalized. And we would have
> welcome a template and terminology easy to re-use (my colleague Robina
> Clayphan kept on complaining that we were not doing a very good work with our
> domain/ranges and cardinality/occurrence notions :-) )
I think we are agreeing that support for "templating profiles" is the goal.
Tom
> A similar approach was applied to two other profiles I've seen recently in my "community":
> - DPLA application profile: http://dp.la/map
> - one profile made for the EuropeanaFashion.eu project, which re-uses the same
> approach as EDM (unfortunately I've got no public document yet).
[1] http://dublincore.org/usage/meetings/2006/04/profile-review/2005-10-05.danbri-dcap-draft.txt
--
Tom Baker <[log in to unmask]>
|