Dear all,

In the current DCAM discussion, we all agree that "examples" will be key, but
we are not making much progress towards specifying what an "example" (or
"pattern") should look like (see the range of possibilities at [1]).  Attached
below are some thoughts from Dan Brickley -- originally posted eight years ago
and re-posted on various lists several times since then, most recently in
public-lld [2].  

Defining "Dublin Core application profiles" as "collections of descriptive
patterns, community conventions and multi-vocabulary metadata structures used
by members of the Dublin Core community", he suggests that application profiles
-- documents of such patterns and conventions -- can range from
natural-language descriptions to machine-readable representations.  Such
documentation may include:

-- "exemplar instance documents" (i.e., what we are calling "records") indicating
   expected usage, and expressed in a particular concrete syntax with a defined
   mapping or transformations to DCAM (e.g., hypothetically, Schematron);

-- exemplar queries illustrating the descriptive patterns either for a specific
   concrete syntax (e.g., XPath for Schematron) or in the abstract (e.g., SPARQL
   queries).

Dan's reflections are about application profiles, with DCAM in the background,
but in a follow-up post I'll suggest some implications for our current
re-think of DCAM...

Tom

[1] http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns
[2] http://lists.w3.org/Archives/Public/public-lld/2010Nov/0114.html

On Mon, Nov 15, 2010 at 08:39:19PM +0100, Dan Brickley wrote:
> So chatting with Tom, I remembered something I wrote ~2004/2005 that
> tries to explain the idea of Application Profiles to a Dublin Core
> audience, without attaching it to any particular technical story.
> 
> I'm not claiming it's 100% reusable now, but there might be some text
> or thoughts in there to salvage. The basic idea is that application
> profiles bridge Dublin Core's role as 'community crossroads' with
> technical concerns about (mostly) RDF graph patterns. And that even
> the slides or audio from a conference talk on some local use of DC is
> a valid, valuable form of 'application profile documentation'.
> 
> Dan
> 
> 
> >From http://dublincore.org/usage/meetings/2006/04/profile-review/2005-10-05.danbri-dcap-draft.txt
> 
> [[[[
> A Proposal for Dublin Core Application Profiles
> 
> Dan Brickley
> 
> 
> Dublin Core Application Profiles are collections of descriptive patterns,
> community conventions and multi-vocabulary metadata structures
> used by members of the Dublin Core community.
> 
> A variety of descriptive techniques are available to the community
> in support of this, combining human oriented and mechanical
> approaches depending on the level of formality, precision and machine
> checkability appropriate. Application Profiles are grounded in real world
> metadata practice, user needs and local priorities. As such they
> typically express constraints and information needs that simultaneously
> extend and restrict global vocabulary standards such as those maintained
> by DC itself.
> 
> A DCAM community serves as a forum for ongoing documentation of
> these restrictions and extensions, relying on the DC Abstract Model
> (and associated formalisms such as RDF) to ensure that a consistent
> approach to description is taken by all Application Profiles. 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. Such
> techniques can improve the multilingual accessibility of the profile's
> documentation, eg. by allowing human-oriented summaries to be
> automatically generated in a variety of natural languages. The remainder
> of this document outlines some technical approaches that can be used
> when documenting an application profile.
> 
> A DC Abstract Model
> 
> There are various machine-readable ways in which we can
> represent the  descriptive patterns, community conventions and
> vocabulary-mixing scenarios relevant to some DC community of interest.
> 
> These techniques are usually grounded in tools and software via some
> specific binding of the Dublin Core Abstract Model, and MAY be grounded
> via a syntax-neutral abstract binding such as RDF's (ie. a concrete grounding
> that itself supports multiple DCAM-compatible notations).
> 
> 1. DCAM Binding Type
> 
> A DCAM profile MAY restrict itself to a subset of the possible
> DC Abstract Model bindings.
> 
> For example, it may specify that compliant instance data be
> expressed using a specific named binding (such as DC-in-XHTML).
> 
> Restrictions on binding type SHOULD specify the specific version of
> a DCAM concrete binding.
> 
> 
> 2. Document Exemplars
> 
> DCAM documentation MAY include 1 or more examplar instance documents
> indicating typical expected usage.
> 
> Exemplar instances MUST be relative to named DCAM bindings, ie. if
> sample RDF/XML is shown, some version of a DC-in-RDF Abstract Model
> binding would be named.
> 
> Notes: Examplar document instances can be useful for user-facing
> documentation, since actual examples are often more accessible and
> understandable than schema-level abstractions.
> 
> 3. Document Instance Syntactic Restrictions (eg. DTDs)
> 
> For DCAM bindings that specify a textual notation (typically but
> not always XML based), any relevant syntactic profiling mechanisms
> MAY be used.
> 
> For example, XML DTDs, Relax-NG or W3C XML Schemas, or Schematron
> schemas could all be used to express restrictions and extensions
> for an application profile, indicated in terms of XML-validatable
> rules, can be used.
> 
> Notes:
> The expression of syntactic restrictions in XML, although relative
> to a specific textual notation, provide a powerful and industrially
> accepted mechanism for expression information needs, shared expectations etc.
> 
> This technique can be used against RDF/XML and non-RDF XML instance
> formats.
> 
> For non-XML RDF formats, techniques such as W3C's GRDDL can be used
> to indicate transformation technques (eg. using XSLT) that can
> convert instances into DCAM-compatible abstractions and hence into
> other formats. These transformations can ensure that instance data
> can be converted into other DCAM bindings; however there is no known
> mechanism for translating syntactic-binding level constraints into
> their equivalent in other bindings.
> 
> RSS 1.0 is an example of a document format that has additional
> non-RDF syntactic constraints (XML nesting structures, required element
> patterns etc.). These conventions can be captured to varying degrees
> using various XML schema languages.
> 
> Note also that RDF-based profiles need not necessarily using DC terms
> in their instances data, since mappings to DC terms can be expressed
> within schemas using RDFS/OWL technology.
> 
> 4. Namespace and Term Enumeration
> 
> A simple technique for indicating an Application Profile is to list
> the namespaces that are typically used in instance data.
> The profile SHOULD indicate these namespaces using URIs.
> 
> DCAPs SHOULD indicate the status of any enumerated list of namespaces,
> ie. whether the list is closed, open/extensible, mandatory, etc.
> 
> At a finer granularity, profiles MAY list metadata terms that
> are typically used in instance data. The profile SHOULD indicate
> these terms using URIs.
> 
> TODO: @@pointers to Schemas project etc proposals
> 
> 
> 5. Use Case Query Patterns
> 
> An Application Profile MAY characterise the descriptive patterns
> important in some community of practice by expressing use cases
> in terms of a query language (or other data access mechnism)
> for some DCAM binding.
> 
> 5a. Syntactic query patterns
> 
> For profiles presented in terms of a concrete syntactic binding
> (techniques (2) and (3)), syntax-specific data matching and query
> languages (eg. XPath, XSLT, XQuery)  MAY be used to document 1 or
> more common query structures. The Schematron language provides a
> suitable high level approach for using XPath to document metadata
> expectations in this way.
> 
> 5b. Abstract query patterns
> 
> Profiles MAY document expected use cases in terms of abstract
> query patterns, ie. structured in terms of abtract metadata
> statements, properties and URIs rather than in terms of a
> textual binding of the DCAM.
> 
> Given the close relationship between DCAM and RDF, any RDF
> query language or data access formalism will be applicable to
> this task. W3C's SPARQL language offers particular facilities
> (such as datatyping and optional patterns) that make it a good
> choice here.
> 
> An Application Profile is not itself a collection of such queries.
> Rather, an Application Profile's documentation MAY be augmented with
> 1 or more indicative queries, provided as a way of linking
> application requirements, usage scenarios, user-needs with
> formally represented patterns of properties and metadata statements.
> 
> For example, the following query indicates a pattern for using
> Dublin Core, FOAF and SKOS vocabularies together for the purpose
> of finding the interests of colleagues of some specified Agent.
> Note that this is a highly task-centric pattern, and not an
> general abstract pattern. Profile documentation MAY present a
> range of indicative queries, illustrating both specific scenarios
> and more general vocabulary combination patterns.
> 
> (@@todo: fix SKOS stuff to be accurate!)
> 
> eg. 1: AP Use Case - "combining DC, FOAF + SKOS for
> 	locating colleague subject interests"
> 
>  PREFIX dc: <http://purl.org/dc/elements/1.1/>
>  PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>  PREFIX skos: <http://www.w3.org/2002/skos-namespace-@@@/>
>  PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> 
>  SELECT ?ilabel ?iblurb ?wphp ?name
> 
>  WHERE
>  {
>     [ rdf:type foaf:Agent;
>       foaf:name ?name;
>       foaf:workplaceHomepage ?wphp;
>       foaf:homepage [ dc:subject [ skos:label ?ilabel; skos:scopeNote ] ]
>     ]
>  }
> 
> 
> 
> This says, in effect,
> 
> "Find us values for ?ilabel, ?iblurb, ?wphp, ?name where
> there is something with a name we call ?name
> that is of type Agent, that has a workplace homepage
> that is ?wphp, and find us SKOS labels and scopenotes for the dc:subject
> of that page".
> 
> Note that this:
> 
>  - combines multiple vocabulary namespaces
>  - describes exact patterns for some (but not all!) ways in which
>    such namespaces can be combined
>  - binds to the DC Abstract Model via RDF
>  - and hence binds to any concrete DCAM syntax
>  - corresponds directly to machine-usable queries, for any data that
>    can be transformed into RDF metadata statements (eg. via GRDDL
>    per (3) above, for non-RDF/XML notations).
> 
> 
> The results of such a query are sets of variable-value associations,
> for example some results of this query above might be:
> 
> 	ilabel: Carpentry
> 	iblurb: Making things with wood
> 	name: Eric Miller
> 	wphp: http://www.w3.org/
> 
> 	ilabel: Photography
> 	iblurb: Taking blurry photos
> 	name: Dan Brickley
> 	wphp: http://www.w3.org/
> 
> 
> ...assuming a dataset in which SKOS, DC and FOAF were combined
> appropriately, ie. FOAF for people stuff, DC for 'subject' (we could
> also have asked for titles, descriptions etc of the agent's homepage),
> and SKOS to elaborate on the details of the subject of the homepage).
> (the simplistic scenario assumption here is that people are
> interested in the topics their homepages cover...).
> 
> 
> ]]]

-- 
Tom Baker <[log in to unmask]>