Re: Question about MARCXML to Models transformation

All


This is on the implicit agenda for tomorrow's telecon, which will be discussing
the problems and limitations arising from the Library standards and linked data
page on the wiki. For this specific issue, see:
 
http://www.w3.org/2005/Incubator/lld/wiki/Library_standards_and_linked_data#Constrained_versus_unconstrained_properties_and_classes
 
Some of the discussion in this thread is going over ground already discussed in
earlier threads ;-) E.g.:
 
http://lists.w3.org/Archives/Public/public-lld/2010Jul/0080.html
 
or:
 
http://lists.w3.org/Archives/Public/public-lld/2010Sep/0057.html
 
Cheers
 
Gordon

On 09 March 2011 at 04:29 Thomas Baker <tbaker@tbaker.de> wrote:

> On Tue, Mar 08, 2011 at 07:50:06PM -0800, Karen Coyle wrote:
> > Tom, are you thinking that this is a statement for the group's report?
>
> If we agree on it, then yes, this is the sort of statement
> I think the report should make.  The text makes reference to
> FRBR and RDA but the point is more general.  If we think it
> is close enough but needs improvement, we should word-smith.
>
> The more general issue is that we need to keep trying to
> distill our discussion into text for the report or we'll
> never make the May target...
>
> Tom
>
> >
> > kc
> >
> > Quoting Thomas Baker <tbaker@tbaker.de>:
> >
> > >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>
> > >
> > >
> >
> >
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > ph: 1-510-540-7596
> > m: 1-510-435-8234
> > skype: kcoylenet
> >
>
> --
> Tom Baker <tbaker@tbaker.de>
>