RE: Library data diagram

Andy,

The "metadata record" use case doesn't seem that different to me. For
example, we could content-negotiate representations of a MARC bib record
in a variety of models including FRBR OWL AND a DC application profile:

http://example.org/bib/12345/x-dc.rdf 
http://example.org/bib/12345/frbr.rdf
http://example.org/bib/12345/marc21.xml
http://example.org/bib/12345/marc21.mrc
etc.

In the FRBR OWL representation, a lightweight connection between
"BibRecord" and FRBR could arguably be made like so:

<owl:Class rdf:about="&ex;BibRecord" />

<owl:ObjectProperty rdf:about="#&ex;describes">
  <rdfs:domain rdf:resource="&ex;BibRecord" />
  <rdfs:range rdf:resource="&frbr;Manifestation" />
</owl:ObjectProperty

<ex:BibRecord rdf:about="http://example.org/bib/12345">
  <ex:describes>
    <frbr:Manifestation
rdf:about="http://example.org/manifestation/98765">
...
    </frbr:Manifestation>
  </ex:describes>
</ex:BibRecord>

The interesting information in the MARC record can then be expressed
using FRBR OWL. "Application profiled" DC seems like one of many
possible variant representations to me.

Jeff


> -----Original Message-----
> From: Andy Powell [mailto:andy.powell@eduserv.org.uk]
> Sent: Wednesday, September 01, 2010 11:26 AM
> To: Young,Jeff (OR); Thomas Baker; Karen Coyle
> Cc: public-lld@w3.org
> Subject: RE: Library data diagram
> 
> > I have the feeling that "application profiles" aren't necessary for
> OWL
> > vocabularies because they are relatively self-explanatory. DC
> > vocabularies don't use OWL so they have to be explained with
> > "application profiles".
> 
> Hmmm... not really.
> 
> OWL constraints essentially apply to the world (or that portion of the
> world that it of interest) - "a 'daughter' can only have one
'mother'".
> 
> Application Profiles constrain/describe what the DC Abstract Model
> calls Description Sets (what we might have called metadata records in
> the past) - collections of one or more Descriptions. Application
> Profiles do not describe vocabularies.
> 
> Andy
> 
> --
> Andy Powell
> Research Programme Director
> Eduserv
> t: 01225 474319
> m: 07989 476710
> twitter: @andypowe11
> blog: efoundations.typepad.com
> 
> www.eduserv.org.uk
> 
> 
> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Young,Jeff (OR)
> Sent: 01 September 2010 16:08
> To: Thomas Baker; Karen Coyle
> Cc: public-lld@w3.org
> Subject: RE: Library data diagram
> 
> I have the feeling that "application profiles" aren't necessary for
OWL
> vocabularies because they are relatively self-explanatory. DC
> vocabularies don't use OWL so they have to be explained with
> "application profiles". IMO, Linked Data is easier to understand if it
> the resources are based on OWL. Comments?
> 
> dc: http://purl.org/dc/elements/1.1/
> dcterm: http://purl.org/dc/terms/
> dcam: http://purl.org/dc/dcam/
> dctype: http://purl.org/dc/dcmitype/
> others?
> 
> Jeff
> 
> > -----Original Message-----
> > From: public-lld-request@w3.org [mailto:public-lld-request@w3.org]
On
> > Behalf Of Thomas Baker
> > Sent: Wednesday, September 01, 2010 10:30 AM
> > To: Karen Coyle
> > Cc: public-lld@w3.org
> > Subject: Re: Library data diagram
> >
> > Thank you, Emmanuelle, for drawing up the comparative
> > diagrams [1] and thank you, Karen, for getting the ball
> > rolling on discussion.
> >
> > A comment specifically on Singapore Framework [2]...
> >
> > On Tue, Aug 31, 2010 at 08:38:36PM -0700, Karen Coyle wrote:
> > > The Singapore Framework places guidance rules outside of the flow
> of
> > > vocabulary and DCAP development. This makes me think that in SF
the
> > > guidance rules are developed and applied after the other steps
> toward
> > > an application profile have taken place.
> >
> > As I see it, the SF diagram is intended to show how the
> > components of an "application profile" relate to each other
> > and to underlying foundational standards (RDF).
> >
> > The diagram does also suggest a workflow, and I too like to
> > present it this way -- starting with Functional Requirements,
> > through defining a Domain Model, specifying a Description Set
> > Profile and, finally, creator a Data Format, with the designer
> > "dipping down" one level to create new or cite existing domain
> > models and vocabularies.  And as a rough approximation, this
> > seems like a reasonable way to proceed as long as it is not
> > applied too mechanically.  In the end, though, SF is meant
> > to depict less a specific sequence of tasks than a picture of
> > how things relate.
> >
> > >                                          This is accurate in terms
> of
> > > Dublin Core metadata, which was developed initially without actual
> > > guidance rules.
> > >
> > > In Emmanuelle's diagram of library metadata, the guidance rules
> > appear
> > > to precede the vocabulary. This is accurate in terms of library
> > > metadata, in which the vocabularies arise from the guidance rules.
> > >
> > > These two models, DC and libraries, seem to me to be the extremes
> of
> > > the development continuum. In libraries the guidance rules are the
> > > most important aspect of the metadata creation activity, and in
> > Dublin
> > > Core they can almost be considered unnecessary.
> >
> > If for libraries, guidance rules are the point of departure for
> > metadata design, then "support for guidance rules" would quite
> > simply need to be defined as a key functional requirement.
> >
> > If this is done, then the metadata creation workflow in
> > libraries can be seen as fitting both the Singapore Framework
> > view and its implied workflow (which starts with Functional
> > Requirements) -- only that, in this case, the functional
> > requirements may be unusually heavy on existing guidance
> > rules...
> >
> > Tom
> >
> > [1]
http://www.w3.org/2005/Incubator/lld/wiki/File:LayeredModelV3.pdf
> > [2] http://dublincore.org/documents/singapore-framework/
> >
> > --
> > Tom Baker <tbaker@tbaker.de>
> >
> 
> 
>

Received on Wednesday, 1 September 2010 16:39:15 UTC