Re: Library data diagram

Note: This email and an article were sent a while ago (Sept. 4) but it did not seem to be in the archive (thanks to Karen who found the problem). Yesterday I tried again but it still did not pass the listserv due to the file size of the attachment.  So, based on the suggestion of the monitor I put a PDF version of the paper on our website.  Here is the URL of the article:

http://nkos.slis.kent.edu/FRSAR/DC2010_FRBR4APDomainModel.pdf

What 'Fig 6' and 'Fig 7' Jeff and I referred to in previous emails are all in the paper.
Marcia

FRBR: A Generalized Approach to Dublin Core Application Profiles
Abstract: According to the Singapore Framework, any development of a Dublin Core Application Profile
(DCAP) has to include the creation of a domain model. DC Scholarly Works Application Profile
(SWAP) was the first one explicitly using Functional Requirements for Bibliographic Records
(FRBR) model in creating its domain model. FRBR has recently been extended with Functional
Requirements for Authority Data (FRAD) and Functional Requirements for Subject Authority
Data (FRSAD) thus forming the so-called FRBR family. This paper first further develops the
SWAP domain model to incorporate the FRBR family models. Then a generalized FRBRfamily-
based DCAP domain model is presented to be used as the basis for specific domain
application profiles.


------ Forwarded Message
From: <ZENG>, "ZENG, MARCIA" <mzeng@kent.edu>
Date: Sat, 04 Sep 2010 22:42:12 -0400
To: "Young,Jeff (OR)" <jyoung@oclc.org>, Thomas Baker <tbaker@tbaker.de>
Cc: Andy Powell <andy.powell@eduserv.org.uk>, Karen Coyle <kcoyle@kcoyle.net>, <public-lld@w3.org>
Conversation: Library data diagram
Subject: Re: Library data diagram

Jeff,
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.
Best,
Marcia


On 9/4/10 5:06 PM, "Young,Jeff (OR)" <jyoung@oclc.org> wrote:

Tom,

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.

Jeff

> -----Original Message-----
> From: Thomas Baker [mailto:thomasbaker49@googlemail.com] On Behalf Of
> Thomas Baker
> Sent: Saturday, September 04, 2010 3:48 PM
> To: Young,Jeff (OR)
> Cc: Andy Powell; Karen Coyle; public-lld@w3.org
> 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
coupled
> > 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
maddening
> > 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
is
> > 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] http://dublincore.org/documents/abstract-model/
> [2] http://dublincore.org/documents/dc-dsp/
> [3] http://www.w3.org/2001/sw/wiki/JointMeeting2010
>
> --
> Thomas Baker <tbaker@tbaker.de>
>





------ End of Forwarded Message