On Tue, 15 Aug 2000, Carl Lagoze wrote:
>
> Thanks for circulating your position paper on applications profiles [1].
> I read it with interest and think that it raises a number of interesting
> issues that need to be raised in the context of DCMI. Put together with
> Tom Baker's grammar paper [2] and my simplicity and complexity paper [3]
> it opens up an interesting context for conversations. To start the ball
> rolling here is my perception of areas of agreement and possible
> disagreement.....
Thanks for your comments, I've just been reading your excellent paper and
recognise the significance of separating out different 'entities' such as
agents, roles, documents in an 'event-aware' data model.
A few brief notes in reply:
....
> If I read your proposal correctly, my impression is that you formulate a
> metadata architecture whereby DC elements (e.g., creator) will be
> intermixed with other community/application specific elements (from
> separate namespaces). Such intermixing implies a 'building block'
> approach to creating metadata descriptions. While such an approach
> might seem appealing I find it possibly inconsistent with some of the
> thinking about DC 'statements' as described in Tom's paper [2].
>
I personally do not see application profiles as limited to the DCMES, the
intention is that elements from other namespaces might also be included in
an applicatio profile. The intention of the paper on application profiles
is to document what we see happening in implementations, formalising
current practice. The impetus is to enable implementations to share and
re-use schemas, and to enable software tools to access 'published'
schemas.
> As stated by Tom in [2], DCES is essentially a metadata pidgin that can
> express sets of statements of quite limited nature - i.e. the
> limitations of qualification and the notion of an 'appropriate literal'.
> Given this, the use of DC elements in an application profilie would be
> rather restrictive. For example, I could use DC:CREATOR element for
> only the purpose of providing a name. However, as is well know many
> communities wish to describe the entities that are included in DCES
> semantics in a much richer fashion; e.g., the many discussion we have
> had about agent attributes and the agent core issues. I'm confused then
> about how one would use applications profiles in such a context.
I have been prompted by comments received since circulating the paper to
think a little more about expression of application profiles, particularly
as RDF Schemas. It seems to me that it should be possible to describe an
application profile that contains more than one namespace in an RDF
Schema. More than that it should be possible to describe such a schema
where elements are associated with the description of different 'classes'
or entities e.g. collections, locations, agents
I see no reason why application profiles cannot have the same richness as
element sets that describe different classes??
> I have parallel elements using something like DC:CREATOR for a simple
> name and than elements from another namespace for a more complex creator
> description (e.g., the sort of thing that vcard does) that would
> probably also include and duplicate the creator name?
I don't think this would happen in a real implementation? Or maybe this is
a misunderstanding .... I fully agree that DCMES and other element sets
are the basis for 'views' onto underlying data. I see application profiles
as providing a definition of such a 'view' in real life implementations,
in that such implementations rarely if ever use a 'standard' element set
with no extensions or local usage.
Given that an application profile is a 'view' it is unlikely to contain a
'simple' and 'rich' version of the same element. I think this would have
pretty detrimental effect on retrieval. What is quite likely is that
one service might describe the same resource (using the same
underlying data) by means of richer or more simple 'views'
depending on the target audience e.g. researcher v. schoolchild.
I guess that a specific implementation might have a requirement to bundle
together different descriptions of the same resource, descriptions created
according to different application profiles. This I think then *would*
require the 'packages' as outlined in the Warwick Framework document.
.....
.....
> semantics). Such a model would allow DCES to fulfill its very important
> role as a model for interchange of simple cross-domain resource
> discovery metadata, without trying to mix it in perhaps messy ways with
> more complex descriptive semantics.
>
I think there is a middle ground where services are looking for a
mixture of simple metadata with a little richness:-) These
implementations are not up for the investment required to create
rich descriptions of whatever flavour. However this, I believe is a
different issue. What we do know is that whatever element set is provided,
local usages will be established. We need to provide a means for
implementors to share these schemas otherwise there will be effort wasted
in their proliferation.
Sorry this is rather rushed....
Rachel
---------------------------------------------------------------------------
Rachel Heery
UKOLN (UK Office for Library and Information Networking)
University of Bath tel: +44 (0)1225 826724
Bath, BA2 7AY, UK fax: +44 (0)1225 826838
http://www.ukoln.ac.uk/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|