Re: Proposed text for section on application profiles

Note that the evolving langauge here is being to parallel DOI community's
definition and practice; see the snippet from the DOI handbook below. Not
explicitly expressed below, but current practice, is the listing of WSDL-based
service interface definition URLs as metdata elements within an AP definition.
Also, APs are named objects themselves; one or more APs may be referenced in a
DOI-named object's metadata.

<doiSnip>
4.1.5 Metadata and DOI Application Profiles

Each DOI is associated with one or more Application Profiles (APs); a grouping
mechanism. DOIs with the same AP share some common characteristics. A DOI
Application Profile (DOI-AP) is the functional specification of an application
(or set of applications) of the DOI System to a class of intellectual property
entities that share a common set of attributes. It answers for a given DOI the
questions:

* what can I find out about this entity through the DOI System (metadata)?
* what can I do with this DOI through the DOI System (services)?

Application profiles are dealt with more fully below. The definition of a
DOI-AP involves specifying not only the metadata to be declared alongside a
DOI for an entity within that DOI-AP, but also the procedural and commercial
rules relating to the exploitation of that metadata.

The three main constituents of an AP are:

* Registration requirements
* Metadata requirements
* Available services

All entities identified with a DOI must be assigned to at least one DOI-AP.
They may be assigned to more than one AP, in which case the registrant must
follow the rules laid down by each DOI-AP to which the entity is assigned. The
question of which DOI-AP or APs any particular entity should be assigned to is
a matter for the discretion of the Registrant.

Application Profiles should be thought of principally as a grouping mechanism;
they are akin to flags, i.e. attributes of the DOI labelling a DOI as of a
certain type, rather than "containers" in their own right; they can be
considered concepts. We do not think it useful to treat APs as self-standing
entities other than for internal management purposes.

</doiSnip>

----- Original Message ----- 
From: "Tansley, Robert" <robert.tansley@hp.com>
To: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>; <www-rdf-dspace@w3.org>
Sent: Friday, July 11, 2003 9:28 AM
Subject: RE: Proposed text for section on application profiles


>
> OK Mark, how about the following:
>
> Often, the requirements of a particular community are not exactly met by an
existing schema or vocabulary.  To avoid having to come up with a new schema
from scratch, the community may produce an application profile.  Application
profiles are ``schemas which consist of data elements from one or more
namespaces, combined together by implementors, and optimized for a particular
local application''\cite{metadataprinciples}.
>
> An application profile may also express rules and `best practice' guidelines
for the use of those schema and vocabularies.  These are sometimes used
because there is a perceived problem that schema languages, DTDs, ontology
languages and suchlike don't provide a formal way of capturing deployment
practices.  In other words, there are many things about an application, and
its  structuring and organisation of data, which are not captured by the
general schema/vocabulary description for Dublin Core, MeSH, etc.
>
> For example, part of an application profile might look like this:
>
> \begin{quote}
> In ILRT's Biomedical Image Archive we use Dublin Core title/description
properties. Each title should begin with a capital letter, and end with a full
stop. Titles are mandatory in the biomed database. Descriptions are optional,
but should not exceed 1000 characters. The values of dc:subject are drawn from
the MeSH classification system. We write dc:date in ISO8601 and use the date
that the image was digitized.
> \end{quote}
>
> Another good example of an application is the Library Application Profile of
Dublin Core \cite{dclibap} (used by DSpace).
>
> Application profiles may be defined informally, as prose meant for human
consumption, or more formally.  For example, there is an XML schema for METS
application profiles \cite{metsappprofile}.  The content of these profiles is
almost always for humans and is application rules for the schema as it applies
in a particular context.  While Machine-interpretable application profiles are
useful for some purposes (e.g. tailoring a UI) this can often be handled by
the schema language directly.
>
>  Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624
>
> > -----Original Message-----
> > From: Butler, Mark [mailto:Mark_Butler@hplb.hpl.hp.com]
> > Sent: 03 July 2003 12:13
> > To: (www-rdf-dspace@w3.org)
> > Subject: RE: Proposed text for section on application profiles
> >
> >
> >
> > Hi Rob
> >
> > My suggestion would be to re-order this slightly because to
> > my mind the most important point about application profiles
> > is they are schemas that re-use
> > data elements from existing schemas, avoiding the need for
> > communities to create schemas from scratch. Then the
> > secondary point is that application profiles are not just
> > technical schema descriptions, but also comprise of
> > guidelines about best practice for using that schema. Some of
> > the constraints in examples the IRLT's biomedical image
> > archive example could be represented syntatically, for
> > example in a database field validation description so need
> > not just be textual descriptions.
> >
> > cheers,
> >
> > Dr Mark H. Butler
> > Research Scientist                HP Labs Bristol
> > mark-h_butler@hp.com
> > Internet: http://www-uk.hpl.hp.com/people/marbut/
> >
> > > -----Original Message-----
> > > From: Tansley, Robert [mailto:robert.tansley@hp.com]
> > > Sent: 02 July 2003 19:29
> > > To: (www-rdf-dspace@w3.org)
> > > Subject: Proposed text for section on application profiles
> > >
> > >
> > >
> > > I hope people don't mind, I basically spliced together the
> > > comments made on the list and added a couple of references.
> > > (Excuse the LaTeX 'boilerplate')...
> > >
> > > In addition to schema and vocabularies, in many domains there
> > > exist rules and `best practice' guidelines for the use of
> > > those schema and vocabularies.  These are sometimes used
> > > because there is a perceived problem that schema languages,
> > > DTDs, ontology languages and suchlike don't provide a formal
> > > way of capturing deployment practices.  In other words, there
> > > are many things about an application, and its  structuring
> > > and organisation of data, which are not captured by the
> > > general schema/vocabulary description for Dublin Core, MeSH, etc.
> > >
> > > These application profiles have been defined as ``schemas
> > > which consist of data elements from one or more namespaces,
> > > combined together by implementors, and optimized for a
> > > particular local application''\cite{metadataprinciples}.
> > >
> > > For example, part of an application profile might look like this:
> > >
> > > \begin{quote}
> > > In ILRT's Biomedical Image Archive we use Dublin Core
> > > title/description properties. Each title should begin with a
> > > capital letter, and end with a full stop. Titles are
> > > mandatory in the biomed database. Descriptions are optional,
> > > but should not exceed 1000 characters. The values of
> > > dc:subject are drawn from the MeSH classification system. We
> > > write dc:date in ISO8601 and use the date that the image was
> > > digitized.
> > > \end{quote}
> > >
> > > Another good example of an application is the Library
> > > Application Profile of Dublin Core \cite{dclibap} (used by DSpace).
> > >
> > > Application profiles may be defined informally, as prose
> > > meant for human consumption, or more formally.  For example,
> > > there is an XML schema for METS application profiles
> > > \cite{metsappprofile}.  The content of these profiles is
> > > almost always for humans and is application rules for the
> > > schema as it applies in a particular context.  While
> > > Machine-interpretable application profiles are useful for
> > > some purposes (e.g. tailoring a UI) this can often be handled
> > > by the schema language directly.
> > >
> > >  Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624
> > >
> >
>
>

Received on Friday, 11 July 2003 10:32:10 UTC