W3C home > Mailing lists > Public > public-lld@w3.org > March 2011

RE: Question about MARCXML to Models transformation

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Wed, 9 Mar 2011 10:12:49 -0500
Message-ID: <52E301F960B30049ADEFBCCF1CCAEF590BBB7508@OAEXCH4SERVER.oa.oclc.org>
To: "Thomas Baker" <tbaker@tbaker.de>, "public-lld" <public-lld@w3.org>
Tom,

I think there are two possible solutions to consider. Personally, I
prefer the latter:
	1) lighten the constraints
	2) add subclasses to WEMI (and possibly a superclass) and update
the domain/range of properties so the constraints are more naturally
intuitive

Jeff

> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Thomas Baker
> Sent: Tuesday, March 08, 2011 10:00 PM
> To: public-lld
> Subject: Re: Question about MARCXML to Models transformation
> 
> On Tue, 8 March, Ross wrote:
> > This is not to say that the FRBR model is wrong or even necessarily
> flawed.
> > I just think that applying it verbatim to RDF through OWL with an
> > application profile that is intended to enforce its rules is more
> likely a
> > barrier to adoption than it is insurance of semantic
> interoperability.
> 
> On Tue, 8 March, Jeff wrote:
> > The constraints found in OWL could be enforced by another layer such
> as
> > Pellet ICV or Application Profiles, but we shouldn't assume these
> layers
> > are implied in the "strictness of FRBRer".
> 
> On Tue, Mar 8, 2011 at 4:06 PM, Richard Light
> <richard@light.demon.co.uk> wrote:
> > I strongly agree with the thought that an entity can be given a URL,
> and
> > thereby you can finesse the need for the "concept is the sum of its
> > properties" approach. We will have many similar cases in the museum
> world,
> > where information about an entity of interest (person, place, event,
> ...)
> > will be incomplete, or uncertain, or both. This shouldn't stop us
> from
> > asserting what we _do_ know (or believe).
> 
> To summarize, can we say the following?
> 
> FRBR and RDA can improve the precision of resource description
> and increase the opportunities for sharing descriptions at
> various levels by making modeling distinctions grounded in
> a coherent intellectual model.
> 
> However, for the linked data context, outside of the library
> silo -- where knowledge about the things being described may
> be imperfect, where the people making descriptions may have
> an imperfect grasp of the models or of their applicability,
> and where people may have data or software that lack clear
> support of the models -- FRBR and RDA should be made available
> for use in a form that is ontologically tolerant.
> 
> The sort of strict enforcement of rules and that served the
> cause of data sharing in a time when data exchange required
> the integrity of shared formats is not only not necessary
> in the more loosely aligned linked data context - it is
> counterproductive.
> 
> The FRBR and RDA vocabularies can be defined in an
> ontologically tolerant manner, such that data which uses the
> models imperfectly -- or data about things to which the models
> imperfectly apply -- will not raise fatal exceptions when
> linked with data that may be simpler, vaguer, or simply based
> on different models.  Apparent misalignments, or contradictions
> to the logic of the models, or gaps in descriptions, should
> be flagged with nothing stronger than helpful error messages.
> 
> Application profiles, whether defined using OWL constraints
> or through other means, still provide a way to constrain the use
> of such vocabularies to an arbitrary degree of strictness
> for the purposes of enforcing data integrity within a silo.
> 
> Hard-coding such constraints into the vocabularies themselves
> imposes that ontological strictness on all downstream users
> of the vocabularies, thus raising the bar to their adoption
> and compromising their potential impact outside of the
> library world.
> 
> Tom
> 
> 
> --
> Tom Baker <tbaker@tbaker.de>
> 
Received on Wednesday, 9 March 2011 15:14:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 March 2011 15:14:17 GMT