Re: Library data diagram

Hi, Jeff,
Thanks for the great work.  We need to point out that fig. 6
needs to be looked at in conjunction with fig 7., which means: all entities
have appellations. Title is an appellation of work.  Therefore that example should be fixed.
Regards,
Marcia

On 9/8/10 11:20 PM, "Young,Jeff (OR)" <jyoung@oclc.org> wrote:

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

My impression is that FIG 6 is being proposed as the foundational model
on which all DC application profiles will be an extension. This is why
my example is limited to "high-level relationships". I would argue,
though, that FIG 6 *IS* a model and thus satisfies the mold for being a
DC application profile itself. I assume the use cases you give below
would be extensions of this model/profile.

> 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,

The model.xsd I created is a reflection of the limits of this
foundational model. Fortunately XML Schemas are extensible and can
include elements from multiple namespaces (ideally resolvable to OWL or
RDF vocabulary terms).

For example, FRBR specifies a "title of the work" property on "Work"
that is missing in the FIG 6 model. One application profile could prefer
dc:title and another frbr:titleOfTheWork. In either case, the property
is already named in an ontology/RDF vocabulary so there is no need for
additional ontology work. What is needed, though, are two new XML
Schemas that import the common foundational FIG 6 model.xsd in order to
enhance the <xsd:complexType type="WorkClassType"> constraint with the
additional element(s). I suspect your other examples would fit this
paradigm:

> e.g.:
>
>     Subjects are to be taken from LCSH.

This could be implemented using xsd:restriction on the URI pattern for
hasAsSubject/@rdf:about match the LCSH subject heading URIs.

>     Dates must be formatted using the W3C date format.

I'm rusty on my XSD conventions, but I assume this could be implemented
by using xsd:date or xsd:dateTime on the date element type.

>     The described resource must have a title.

This could be specified in XML Schema using minOccurs="1"

>     Titles may be in English or Spanish only.

I'd have to dig around, but I assume these constraints could be imposed
using XML Schema somehow.

>     There may be no more than eight authors.

maxOccurs="8"

>     The value for X must be drawn from the following list.
>     The described resource must be one of the following six types.

I assume XML Schema enumeration would satisfy the first one and the
relationships in my example involving Agent should demonstrate
xsd:choice for limiting "types".

>     Authors may not be described in the absence of a described journal
> article.

I can imagine one or two unexpected situations where a real author has
zero journal articles. ;-)

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

The beauty of basing RDF on a domain model is that machines can easily
guess how much of the graph to pull into the representation without
overlap or omissions. That's the philosophy of my work_1.rdf example:
deliver the RDF properties for that individual and trust other
individuals to do likewise. Creating RDF representations that pull in
more or less of the graph requires human decision-making, which is
relatively expensive and inevitably class-specific. I agree, though,
that custom XML Schemas/DC application profiles are a good way to define
the RDF boundary in these situations.

Here is what I imagine a framework could blindly automate from a domain
model by default:

Real World Object: http://example.org/{class-name}/{instance-name} 303
to...
Generic Document: http://example.org/{class-name}/{instance-name}/
content-negotiation to...
Web Document:
http://example.org/{class-name}/{instance-name}/default.html
Web Document: http://example.org/{class-name}/{instance-name}/about.rdf

Here a hypothetical reconfiguration for the class to accommodate the
default representations AND additional representations that pull in more
of the graph:

Real World Object: http://example.org/work/1 303 to...
Generic Document: http://example.org/work/1/ content-negotiate to...

Content-Negotiation defaults:
Web Document: http://example.org/work/1/mashup.html [extra stuff mashed
up in HTML for human convenience]
Web Document: http://example.org/work/1/about.rdf [bare properties in
RDF to simplify Linked Data production]

Specialized representations:
Web Document: http://example.org/work/1/default.html [bare properties in
HTML for diagnosing about.rdf]
Web Document: http://example.org/work/1/mobile.html [bar properties
stripped down to essentials for mobile browsers]
Web Document: http://example.org/work/1/mashup.rdf [extra stuff mashed
up in RDF based on a DC application profile/XML Schema]
Etc.

Jeff

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