RE: Library data diagram

I mocked up Figure 6 from the document Marcia sent using OWL/XML Schema.
The files are attached.


*         model.owl - An OWL DL representation of "FIG 6. General DCAP
Domain Model" from the document Marcia sent. This OWL can be validated

o   owl2html.xsl - I wrote this and added a stylesheet reference to
model.owl so people can browse it as HTML.

*         model.xsd - This is an XML Schema representation of model.owl.
I hand-crafted this XSD, but in principle it could be manufactured
directly from the OWL using XSLT or some-such.

*         rdf.xsd - I included this because my XML Schema validator
refuses to accept the "official" RDF XML Schema at 

*         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: 


My use case scenario involves 3 domains: - A DC application profile maintenance agency where
the model.owl and model.xsd documents and extensions are hosted. - An authority agency where some Themas and Nomens
based on the OWL/XSD are maintained and published as Linked Data. - An organization that populates and publishes most of
the classes in FIG 6. (e.g. work_1.rdf) as Linked Data using the


The general "real world object" URI pattern I assumed in the RDF is like




where {class-name} is taken directly from the ontology. The
{instance-names} I used are assumed to be sequential numbers unique to
each class.


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.




From: ZENG, MARCIA [] 
Sent: Saturday, September 04, 2010 10:42 PM
To: Young,Jeff (OR); Thomas Baker
Cc: Andy Powell; Karen Coyle;
Subject: Re: Library data diagram


For the Dublin Core conference we have prepared a paper for FRBRer
family based domain model for application profiles, inspired by the SWAP
model.  With the addition of FRSAD entity we expanded the SWAP domain
model, and proposed a general AP model.  I am attaching the paper for
your information.  We are hoping to get into a discussion in the DC2010
time, but looks like now we should enter the theme earlier.
We are now also using this general model to draft the DCMI-NKOS AP's
domain model.
See the attachment.

On 9/4/10 5:06 PM, "Young,Jeff (OR)" <> wrote:


I'll try to mock up EPrints/SWAP in UML/OWL/XML Schema as I imagine it.
>From there, we can compare/contrast it with DC application profile
approach to see where the overlap and gaps are.

I'm still agonizing over the use cases I've started, but try to have
something ready soon so we can decide if it's worth discussing at the
joint meeting.


> -----Original Message-----
> From: Thomas Baker [] On Behalf Of
> Thomas Baker
> Sent: Saturday, September 04, 2010 3:48 PM
> To: Young,Jeff (OR)
> Cc: Andy Powell; Karen Coyle;
> Subject: Re: Library data diagram
> Hi Jeff,
> On Wed, Sep 01, 2010 at 11:38:19PM -0400, Jeff Young wrote:
> > I assume that resources modeled in OWL (owl:Class,
> owl:ObjectProperty,
> > individuals, etc.) could be "reused" in a DC application profile. I
> > think we're on the same page on this point.
> Yes :-)
> > > In this context, the point of a "DC application profile"
> > > would be to specify the pattern of resource descriptions using
> > > RDF properties and classes.  For example, the application
> > > profile would specify that the property ex:describes be used
> > > when relating an instance of ex:BibRecord to an instance of
> > > resource (which would be inferred to be a frbr:Manifestation).
> > > It would specify the template by which instance metadata,
> > > such as 12345/x-dc.rdf, is created.
> >
> > From this example, it sounds like DC application profiles are
> > with specific conceptual models (e.g. the EPrints model) that
> > more-or-less *could* be represented in OWL.
> A particular DC application profile is based on a particular
> "domain model".  A Domain Model is a model of things
> being described in metadata -- such as, in the case of the
> EPrints/SWAP application profile, an Agent, Scholarly Work,
> Expression, Manifestation, and Item.
> >                                               For sure, the
> > thing about RDF is that there are so many equivalent ways to
> *represent*
> > RDF that it is unreasonably hard for humans to cope. I can believe
> this
> > is an important problem that needs to be solved, but since RDF/XML
> > XML why not create an XML Schema to constrain the OWL individuals
> > instead?
> That was roughly the intention of the approach embodied
> in the DCMI Abstract Model [1] and Description Set Profile
> constraint language [2] -- to provide a language for describing
> your particular model in a way that can be expressed and
> syntactically validated in your syntax of choice (including
> XML Schema), yet maps straightforwardly to triples.
> If the DCAM/DSP approach has been surpassed or superseded by
> better options, I would very much like to get these on the table
> in the joint meeting of LLD XG and the DCMI Architecture Forum
> on Friday, 22 October [3].
> Tom
> [1]
> [2]
> [3]
> --
> Thomas Baker <>

Received on Wednesday, 8 September 2010 22:04:45 UTC