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

Re: FRBR and classes ('frbr:Works in the age of mechanical reproduction'...)

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Tue, 22 Mar 2011 06:13:39 -0700
Message-ID: <20110322061339.908575ejni2qbxj7@kcoyle.net>
To: Dan Brickley <danbri@danbri.org>
Cc: public-lld <public-lld@w3.org>
Quoting Dan Brickley <danbri@danbri.org>:

>> On this last point, are there any scenarios where prototypical
>> characteristics of some Manifestation might inerestingly vary in
>> practice? Most obvious I can think of is number of pages, but I cant
>> think of reasons it would be useful. Reason to ask is that if it were
>> important to describe both the typical and actual values that some
>> property has, then a bit of care is needed to get the rdf
>> representations right.

Manifestations should not vary in their physical description -- if  
they do, then it is a different manifestation. That's the logical  
result of them being mass produced. Items can vary because something  
has changed since production (lost a cover, pages torn out). That  
level of detail is usually only recorded for special items.

There are edge cases, of course. For digital files it can be hard to  
decide where to draw the cut-off for manifestations -- when is a copy  
really a copy? For unique items, it can be ambiguous whether a  
characteristic belongs to the manifestation or the item. (Ambiguous in  
our heads, not so much in the cataloging rules, although I'm not at  
all familiar with that type of cataloging.)

>> Is it ok for these different 'functions' to be making me think both of
>> DC application profiles and also of stored/shared query templates...?

Dan, go for it. Let's see where it takes you.

>> Btw On this business of non-duplication, data sharing standards are
>> intrinsically about having extra copies floating around. If they
>> attach eg the work's subject info directly alongside item properties,
>> that doesn't seem costly. What's costly is *managing* work-level facts
>> separately for each item. so long as things are managed sanely behind
>> the scenes, flat records don't seem such a crime.

This seems to perfectly describe DC APs and query templates. My mental  
vision for our linked data future includes a lot of data "molecules"  
being formed as needed. I think of them as "views" -- which is like a  
query. You could have a place of publication and subjects making up  
the entirety of a view. At that point, however, I believe that you  
have created a new statement, no longer FRBR but using different  
predicates. One thing I cannot quite grasp is what happens to highly  
constrained entities and properties when they are used in this way. Do  
the constraints (e.g. WEMI and the relationships between them) allow  
this type of re-use? If the FRBR property rules say that subjects are  
a property of a Work, and only a property of a work, what does that  
mean for the creation of these molecules? I think one answer is that  
the underlying FRBR-ness is always there, but your view masks it. So  
my place of publication and subjects is really:

place of publication (Manifestation -> manifests -> Expression ->  
expresses -> Work -> hasSubject) subject

If I query some data and retrieve my two end points here, what happens  
to those constraints defined in FRBR? In a practical sense I assume  
that the data re-use will ignore the original definitions and  
constraints imposed by FRBR, but I can't think through what the  
implications of that are. (LD is sometimes like playing 3D chess  
without a chess board. My head crashes early on.)


>> Dan
>>> kc
>>> [1] http://eprints.rclis.org/bitstream/10760/8622/1/Renear_Modeling.pdf
>>> [2] http://kcoyle.blogspot.com/2010/05/frbr-and-sharability.html
>>> --
>>> Karen Coyle
>>> kcoyle@kcoyle.net http://kcoyle.net
>>> ph: 1-510-540-7596
>>> m: 1-510-435-8234
>>> skype: kcoylenet

Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Received on Tuesday, 22 March 2011 13:14:15 UTC

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