On Wed, Mar 14, 2012 at 05:00:59PM -0400, Tom Baker wrote:
> eg. 1: AP Use Case - "combining DC, FOAF + SKOS for
> locating colleague subject interests"
...
> 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 ] ]
> ]
> }
The example above shows a pattern for using four vocabularies to describe
something for a particular purpose ("locating colleague subject interests").
I'd like to suggest a "lower-level" pattern for consideration. Consider the
following (non-exhaustive) possible variants:
1. String value only (using the DC-RDF convention of rdf:value):
:X dcterms:subject :Y
:Y rdf:value "Textile design--China--History"
2. String value with Vocabulary Encoding Scheme:
:X dcterms:subject :Y
:Y rdf:value "Textile design--China--History"
:Y dcam:memberOf <http://purl.org/dc/terms/LCSH>
3. String value with SKOS Concept Scheme:
:X dcterms:subject :Y
:Y skos:prefLabel "Textile design--China--History"
:Y skos:inScheme <http://purl.org/dc/terms/LCSH>
4. Value URI, alone:
:X dcterms:subject <http://id.loc.gov/authorities/subjects/sh85134312>
5. Value URI with (possibly redundant?) context:
:X dcterms:subject <http://id.loc.gov/authorities/subjects/sh85134312>
<id:sh85134312> skos:inScheme <http://purl.org/dc/terms/LCSH>
Is it clearly "best practice" to use one of these variants? Or are there
circumstances in which one might favor one over the other?
Would it be useful to move these examples to a higher level of abstraction --
i.e., express these examples not only as RDF triples, but in XML Schema or
Schematron? If so, is it useful to have an abstract syntax that is one layer
removed from RDF -- e.g., that labels the bits of information shown above as
Property URI, Value URI, VocabularyEncodingScheme URI (or ConceptScheme URI)...
-- in short, an abstract syntax for DCAM?
Note that this example highlights an aspect of the mapping of DCAM to RDF --
its use of rdf:value -- which has, through the evolution of best practice, turned
into Not-Best Practice.
If the potential value of DCAM lies in providing a frame for examples of Best
Practice, is it more important to get the set of examples right or to get the
more generalized abstract syntax right? In the case above, there is more than
one way to do it. Is it perhaps enough to assemble useful examples, starting
with simple patterns like those above, on up to higher-level patterns like the
one Dan presents?
Discuss...
Tom
--
Tom Baker <[log in to unmask]>
|