- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 22 Mar 2011 06:13:39 -0700
- 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.) kc >> >> 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