Hi Jeff,
On Wed, Sep 08, 2010 at 06:04:04PM -0400, Jeff Young wrote:
> * work_1.rdf - This is a mocked up RDF/XML instance of
> dc-ap:Work from the model that conforms to the XML Schema I wrote for
> it. I can send representations of other individuals in the model, but
> they will all look similar. This RDF can be validated here:
> http://www.w3.org/RDF/Validator/uri
...where:
> http://dc-ap.org/ - A DC application profile maintenance agency where
> the model.owl and model.xsd documents and extensions are hosted.
>
> http://x-auth.org/ - An authority agency where some Themas and Nomens
> based on the OWL/XSD are maintained and published as Linked Data.
>
> http://x-lib.org/ - An organization that populates and publishes most of
> the classes in FIG 6. (e.g. work_1.rdf) as Linked Data using the
> OWL/XSD.
My (very) quick and (very) dirty rendering of the work_1.rdf instance metadata
as triples is:
xlibwork:1 rdf:type dcap:Work .
xlibwork:1 schemaLocation "dcap: model.xsd" .
xlibwork:12 rdf:type dcap:Work .
xlibwork:1 dcap:hasPart xlibwork:12 .
xlibwork:13 rdf:type dcap:Work .
xlibwork:1 dcap:hasPart xlibwork:13 .
xauththema:1 rdf:type dcap:Thema .
xlibwork:1 dcap:hasSubject xauththema:1 .
xauththema:2 rdf:type dcap:Thema .
xlibwork:1 dcap:hasSubject xauththema:2 .
xlibexpression:2 rdf:type dcap:Expression .
xlibwork:1 dcap:isExpressedBy xlibexpression:2 .
xlibexpression:3 rdf:type dcap:Expression .
xlibwork:1 dcap:isExpressedBy xlibexpression:3 .
xlibwork:15 rdf:type dcap:Work .
xlibwork:1 dcap:isPartOf xlibwork:15 .
xlibwork:16 rdf:type dcap:Work .
xlibwork:1 dcap:isPartOf xlibwork:16 .
xlibagent:1 rdf:type dcap:Agent .
xlibwork:1 dcap:isSupportedBy xlibagent:1 .
xlibagent:2 rdf:type dcap:Agent .
xlibwork:1 dcap:isSupportedBy xlibagent:2 .
xlibagent:1 rdf:type dcap:Agent .
xlibwork:1 dcap:rightsControlledBy xlibagent:1 .
xlibagent:3 rdf:type dcap:Agent .
xlibwork:1 dcap:rightsControlledBy xlibagent:3 .
> Based on my superficial understanding of DC application profiles, I
> suspect that this extensible OWL/XSD solution could fulfill at least
> some of the intended use cases. The gaps aren't clear to me, though.
I think I see the basic idea here, and I suspect that for many
applications, this way of "constraining" the set of properties
and classes used in instance metadata may be enough. I also see
that the instance metadata focuses on high-level relationships
between resources, agents, and themas.
The approach reflected in DCAM [1], DSP [2], and Singapore
Framework [3], by way of contrast, is designed to encode
syntactic constraints one might want to impose on metadata
records with regard to descriptive details, e.g.:
Subjects are to be taken from LCSH.
Dates must be formatted using the W3C date format.
The described resource must have a title.
Titles may be in English or Spanish only.
There may be no more than eight authors.
The value for X must be drawn from the following list.
The described resource must be one of the following six types.
Authors may not be described in the absence of a described journal article.
... etc ...
I would like to understand better what the requirements for
application profiles are by, say, the RDA community, and how
they map to these two approaches.
Tom
[1] http://dublincore.org/documents/abstract-model/
[2] http://dublincore.org/documents/dc-dsp/
[3] http://dublincore.org/documents/singapore-framework/
--
Thomas Baker <tbaker@tbaker.de>