W3C home > Mailing lists > Public > public-lld@w3.org > September 2010

RE: Library data diagram

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Wed, 1 Sep 2010 23:38:19 -0400
Message-ID: <52E301F960B30049ADEFBCCF1CCAEF5909994400@OAEXCH4SERVER.oa.oclc.org>
To: "Thomas Baker" <tbaker@tbaker.de>
Cc: "Andy Powell" <andy.powell@eduserv.org.uk>, "Karen Coyle" <kcoyle@kcoyle.net>, <public-lld@w3.org>
Hi Tom,

> > 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.
> 
> Okay.
> 
> (I wonder whether the filenames are ideal, because all
> MARC XML records would be called "marc21.xml" when mechanically
> downloaded with, say, "wget", but that's beside the point...)

The URI pattern I'm using isn't based on a folder/file paradigm.
Instead, it is based on the one-to-one-to-many resource hierarchy
implied by Linked Data "303 URIs forwarding to One Generic Document":

http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Subject_Search#Prefac
e_on_URI_patterns

On a different point, Web standards, including Linked Data, never use
the concept of "record". Nevertheless, this concept is still vital to
library thinking, so I think we should model it somewhere in OWL like I
did with the ex:BibRecord class. These "records" could then be
identified and represented in content-negotiable "versions"
(representations) using Linked Data.

Real world object: http://example.org/record/12345 
Generic Document: http://example.org/record/12345/ 
Web document: http://example.org/record/12345/default.html 
Web document: http://example.org/record/12345/about.rdf 
Web document: http://example.org/record/12345/marc21.xml
Etc.

For mass harvesting of "marc21.xml" "records", I would recommend some
"class-level" operation URIs like these rather than sequential GETs
using "instance-level" URIs:

http://example.org/class/bib/download-marc21-xml.zip 
http://example.org/class/bib/feed-marc21-xml.atom 
http://example.org/class/bib/oai-pmh?verb=ListRecords&metadataPrefix=mar
c21.xml 
http://example.org/class/bib/sitemap-marc21-xml 
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
> 
> Okay, though I wouldn't normally expect this
> class to be declared in instance data, e.g., in
> http://example.org/bib/12345/frbr.rdf...?

I included the owl:Class and owl:ObjectProperty for context and didn't
mean to imply they should be delivered with each instance. I would
expect the OWL to be published at a URI more like this:

http://example.org/ontology/bib-0.1/ (content-negotiable for OWL and
HTML)

> > <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.
> 
> I want to make sure we're on the same page here.  AFAICT,
> this same information ("exb:12345 ex:describes exm:98765")
> could be expressed in metadata based on what the Singapore
> Framework calls a "Dublin Core application profile".  Note [1]:
> 
>     The DC notion of the application profile imposes no
>     limitations on whether those properties or encoding schemes
>     are defined and managed by DCMI or by some other agency:
>     the key requirement is that the properties referred to
>     in a DCAP are compatible with the notion of property in
>     the Resource Description Framework.
> 
> Specifically, the notion of application profile described in
> the Singapore Framework is _not_ tied to the use of (any of)
> the fifteen elements of "the Dublin Core" as an RDF vocabulary.

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.

> 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. 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?

> Whether the Singapore Framework should continue to be tied
> specifically to DCAM is currently up for discussion.  However,
> it is not clear to me how an RDF expression of DCAM-based
> metadata [3] -- as
> 
>     http://example.org/bib/12345/x-dc.rdf
> 
> might very well be -- would necessarily be any different from
> what you are calling FRBR OWL:
> 
>     http://example.org/bib/12345/frbr.rdf

My intention for these two URIs was to convey the possibility that
"x-dc" and "frbr" are different conceptual models that are both
derivable from a common "BibRecord". The FRBR vs CiTO ontologies might
be better examples. The triples for these competing models could be
delivered in a shared "about.rdf" representation, but it might also be a
nice feature to deliver them separately as an option. I apologize for
including this unstated use case. 

> The Scholarly Works Application Profile, for example,
> specifies a record consisting of a set of descriptions of
> related instances of FRBR entities (except that it uses [5]
> instead of frbr:Manifestation).

Right! So there's the competing model I was talking about:

http://example.org/bib/12345/frbr.rdf
http://example.org/bib/12345/swap.rdf

Imagine the EPrints model specified using OWL and that SWAP is
implemented using XML Schema to deter variations in the RDF/XML
representation of the OWL individuals.

Jeff

> 
> Tom
> 
> [1] http://dublincore.org/documents/singapore-framework/
> [3] http://dublincore.org/documents/dc-rdf/
> [4]
>
http://www.ukoln.ac.uk/repositories/digirep/index/Scholarly_Works_Appli
> cation_Profile
> [5] http://purl.org/eprint/entityType/Manifestation
> 
> --
> Thomas Baker <tbaker@tbaker.de>
> 
Received on Thursday, 2 September 2010 03:39:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 2 September 2010 03:39:26 GMT