Re: Open Library and RDF

All
 
One of the significant applications I see for WEMI is to further reduce the
duplication that Karen mentioned (currently achieved through record-sharing;
this reduces duplication of effort, but not necessarily of data). In a strong
WEMI model, one Work is related to many Expressions, one Expression to many
Manifestations, and one Manifestation to many Items (this last is relatively
uninteresting, though). The cataloguing process generally starts with the
Manifestation (the thing "in hand"). A strong WEMI model allows the cataloguer
to find an existing Expression for that Manifestation, and instead of
duplicating the Expression data, link to it. If there is no existing Expression,
the cataloguer creates one (as a separate "resource"), and links the
Manifesation to it. Then the cataloguer looks for an existing Work, and so on.
(This raises the issue of URIs for Works, Expressions and Manifestations - see
the Scholarly Works Application Profile (SWAP) [1] - but let's assume the
universal identifier problem gets resolved.) This in turn avoids unnecessary
proliferation of instance triples.
 
Another view is to think of WEMI as a set of packages (bags?) for instance
triples. Each package is aligned with one or more specified user tasks (FRBR
models this), so WEMI allows identification of specific instance triples as
suitable (or not) for a particular user-focussed application. I expect at some
future point that the view that WEMI is for disaggregating the current
monolithic record-centred paradigm of library (and to a more or less extent
archive and museum) practices will be replaced by the view that WEMI is for
aggregating simple metadata statements in real-world applications (the Semantic
Web paradigm?).
 
I think that strong modelling is required to achieve this. Or can it all be done
via application profiles?
 
[1]
http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile
 
Cheers
 
Gordon
 

On 16 August 2010 at 22:22 Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi Tom,
>
>
> > On Mon, Aug 16, 2010 at 03:08:10PM +0200, Antoine Isaac wrote:
> >> In particular, for the FRBR case, I'd favor asserting explicitly that W, E,
> >> M and I are disjoint--if that's what is intended by the designers of the
> >> model. Let's not forget that "No commitment" is also an enemy of minimal
> >> commitment. Given the genericity of FRBR's classes, formal hints can be of
> >> great use for users to understand the model. And indeed it makes a great
> >> difference whether WEMI are disjoint or not.
> >> Also, if people want to use constructs at their face value in a AAA fashion
> >> [1], well, let's allow them to do so. But I don't see why this would be at
> >> the expanse of others' ability to sort out what commits to the model as
> >> agreed by the community from what does not make that commitment. These who
> >> don't want to commit are still free then *not* to "apply" the ontology's
> >> formal semantics.
> >
> > I'm not sure I follow your point.  If WEMI are formally
> > declared as disjoint, then someone may well choose simply
> > to ignore this (as Dan points out they may), but the formal
> > semantics would not go away and would come into play if a
> > reasoner were invoked.  On the other hand, if WEMI were merely
> > declared as disjoint in prose, as a less formal "hint", the
> > intended disjointedness could still be expressed in guidelines
> > and application profiles and inform the creation of good,
> > FRBR-conformant metadata.
>
>
> Yes, but then you prevent the ones who do want to strictly adhere to FRBR in a
> semantic web environment to benefit from a shared formal semantics useful for
> their processes. Ontologies are sold as a way to provide that, and now they
> would have to re-create their own OWL!
>
>
>
> > When I hear there is disagreement among specialist communities
> > about the interpretation of FRBR, I wonder if even the experts
> > may want to associate a given resource with a different WEMI
> > class, and how dire the consequences should be if they did?
> > Can one live with resource A being declared here as an
> > Expression and there as a Manifestation, or should this trigger
> > loud alarms?  If so, might dissenters from the official FRBR
> > line want to break off and create their own expression of FRBR?
>
>
> Well, that's already done, with FRBRoo for example. Far from me from putting
> the blame on FRBRoo creators, really. But in such conditions I don't see why
> there couldn't be another OWL endorsed by FRBR designers as well.
>
> I'm not saying that FRBR should put the disjointness light-heartedly, just to
> please themselves by adding another axiom. But *if* really they know that a
> missing axiom would render their model useless in their eyes, I don't see why
> they would refrain from including it.
>
>
> > Then there is the question of how to link the more heavily
> > specified ontology to more generic models followed outside
> > the library world, as with the layered approach alluded to
> > by Karen.
>
>
> Well, if there is a strong point for such generic models, I don't see why
> there couldn't be defined via superclasses and superproperties. Imagine indeed
> there is a strong case for some applications not making a strong disjointness
> between Expression and Manifestation, for example (a quite made-up one, I
> don't want to take position on that now). This could be reflected by an
> ex:ExpressionOrManifestation class, super-class of both frbr:Expression and
> frbr:Manifestation. I agree that this may provide less interoperability, but
> well if the models are really different I don't see why not respecting this.
>
>   
> >> In the alternative case (i.e., if no formal semantics specified in the
> >> first place) then the first category (the ones who agree on the original
> >> model) will never be "free" to apply them. So we have not much choice if we
> >> want both sides to leave their own life.
> >
> > But is it so black and white?  Does disjointness (for
> > example) need to be declared formally in order to be applied
> > in practice?
>
>
> No, but it helps these users who just want to re-use an existing OWL file and
> not re-invent one themselves. Now, where it could be not fully B&W is if
> several OWL files exist, which represent different levels of commitment.
> Again, not very interoperability-friendly, but if you assume that there would
> be plenty interpretations co-existing anyway thanks to the lack of formal
> specs, you would end up with similar issues.
>
> Antoine
>