Re: Library data diagram

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>

Received on Wednesday, 8 September 2010 23:35:40 UTC