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

Re: Question about MARCXML to Models transformation

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 09 Mar 2011 13:04:28 +0100
Message-ID: <4D776CCC.2020006@few.vu.nl>
To: public-lld <public-lld@w3.org>
+1 here...


> 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
Received on Wednesday, 9 March 2011 12:03:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:43 UTC