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

Help for DC-RDF-TASKFORCE Archives


DC-RDF-TASKFORCE Archives

DC-RDF-TASKFORCE Archives


DC-RDF-TASKFORCE@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-RDF-TASKFORCE Home

DC-RDF-TASKFORCE Home

DC-RDF-TASKFORCE  September 2005

DC-RDF-TASKFORCE September 2005

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Formal expression of dublin core application profiles

From:

Dan Brickley <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Fri, 16 Sep 2005 07:43:21 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (255 lines)

> Hi all,
>
> Just posting some thoughts, drafted while sitting in on discussion of
> DCAPs at UB meeting ...

I like this approach a lot, and have been advocating it on and off for a
while; Libby did some work on this in Squish too, 'Schemarama'. I think
now we have SPARQL it's time to look into it more carefully, so am very
glad you're thinking in this direction too and have worked thru
some examples.

I've just been trying to draft a description of what APs are, that is
consistent with this (copied here below). This is totally rough draft,
just written...

Also conceptually nearby, overlong rambling post on this and validation
c/o http://danbri.org/words/2005/07/30/114


[[
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...).

]]

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2006
March 2006
December 2005
October 2005
September 2005
August 2005


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

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