- From: John S. Erickson <john.erickson@hp.com>
- Date: Fri, 11 Jul 2003 10:27:33 -0400
- To: <www-rdf-dspace@w3.org>
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