JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  March 2012

DC-ARCHITECTURE March 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

DCAM and RDF graph patterns - thoughts from Dan

From:

Tom Baker <[log in to unmask]>

Reply-To:

DCMI Architecture Forum <[log in to unmask]>

Date:

Wed, 14 Mar 2012 17:00:59 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (289 lines)

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]>

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager