Tom:
I take your point, and though I do understand what you're trying to get
at in terms of a broad range of skills needed, I'm a bit frustrated at
how this distinction is being used. The questions you ask that are
supposed to be "data-engineering aspects" are not ones that I would
consider only answerable by a technical person.
Then there's "metadata engineering" which is another thing, or not?
I'd suggest that we not assume that certain questions be answered by one
or another of the "team" that we instead describe what the issues are,
and maybe (maybe) call some of them "technical."
Diane
Thomas Baker wrote:
> Hi Diane,
>
> With reference to the fourth paragraph of [1], you write:
>
> On Sun, Nov 09, 2008 at 03:43:49PM -0500, Diane Hillmann wrote:
>
>> In the fourth paragraph I find the unfamiliar notion of
>> "data-engineering aspects." What does this mean? I thought we were
>> trying to enable people to figure out how to do this, not scare them
>> off! I would just use "aspects" here and dump the off-putting
>> terminology. A little further along we encounter the phrase "metadata
>> engineering." This sounds to me a result of the same sort of thinking
>> that uses "sanitation engineer" to describe the guys who collect garbage
>> (and I include women here, since I saw my first female garbage-person
>> just last week!) Far more worrisome is the effect that this sort of
>> terminology is likely to have on newbies to this environment,
>> particularly librarians, who might be likely to see these terms as
>> boundaries around what they can be expected to tackle. We can't afford
>> that if we want to see this technology proliferate--and I think that's
>> what these guidelines can and should do. This is not rocket science,
>> and we do ourselves no favors in casting it in that manner.
>>
>
> This is a reference back to the second bullet point at the end of the
> Introduction [2], where we say:
>
> It is recommended that application profiles be developed
> as team projects involving, at a minimum, both:
>
> * data content specialists, who are knowledgeable
> in the resources that need to be described an in the
> metadata used in the description of those resources,
> and
>
> * data engineers or architects, who understand how to
> structure the underlying data for interoperability in
> a linked data environment.
>
> The point is that if a profile is to be designed for
> interoperability, the task will require some knowledge and
> expertise in data modeling -- not necessarily on the part of
> "data content specialists", but at least by some members of
> the design team.
>
> Can anyone suggest a better way to make this distinction?
> Is "data architects" any clearer?
>
> Tom
>
>
> [1] http://dublincore.org/documents/2008/11/03/profile-guidelines/#sect-5
> [2] http://dublincore.org/documents/2008/11/03/profile-guidelines/#sect-1
>
>
|