Ah, but we're likely going to want/have to map our data to data using
other conceptual models, whether it maps perfectly or not. We already
map to publisher land, in the sense that we include ISBNs in cataloging
records, that's a mapping. Now, one catalog record can map to multiple
ISBNs (hardcover/paperback), and one ISBN can map to multiple cataloging
records even just in the 'controlled' system of OCLC (one record for a
single volume; another for the multi-volume set; another for a record
with language-of-cataloging (NOT language of text, that's different) in
French.). So, yeah, it's not a nice neat mapping, but we still do it,
and could probably do it in different better ways than we do now.
We're only going to want to do more mappings like that.
Which is part of why having an explicit formal model is so important,
it's the guide to figuring out the best way to map things.
And I still feel like ISTC might be more like a FRBR 'work' than a FRBR
'expression', if it's true that significant changes to the text don't
create a new ISTC. Significant changes to the text (say, remove chapter
3 and replace it with a new chapter 3) are definitely a new expression
from the FRBR point of view. It may be that the way the publisher's
community defines their 'work' entity is that different translations are
different works, while the way we define our work entity different
translations are the same work (but the movie adaptation is a different
work; some OTHER community might define that as the same work!). This
isn't too surprising, that different communities define their entities
in different ways. Again, this is one of the reasons we need explicit
formal domain models, so we know how things have been done, and can map
appropriately.
Jonathan
Kristin Antelman wrote:
> The ISTC overlaps best with Expression, but is unlikely ever to be a
> particularly good fit (e.g., "Works that are entirely graphic, with no
> text, are not eligible for ISTCs."). The ISTC is all about publisher
> needs: rights management, tracking revenue across editions, etc. That
> doesn't mean the ISTC might not be useful for library systems, but like
> the other identifiers we have to work with, it will never map well to
> the FRBR model nor will it be much influenced by the thinking around
> that model. (Publishers have no interest in the Work.)
>
> http://www.myidentifiers.com/multimedia/pdfs/ISTC_overview_ISQv21no3.pdf
>
> -Kristin
>
> Jonathan Rochkind wrote:
>
>> But what about a new edition with a new afterword, or with
>> 'typesetting' errors corrected? Would that be the same ISTC or
>> another one? I think we'd call it a new expression, in either case.
>>
>> But you're probably right, and the implicit non-formalized entity that
>> gets an ISTC assigned is most analagous to our 'expression', although
>> not defined in exactly the same way we might, which is to be expected.
>>
>> Jonathan
>>
>> Karen Coyle wrote:
>>
>>> Quoting Jonathan Rochkind <rochkind_at_JHU.EDU>:
>>>
>>>
>>>
>>>> I _think_ the thing they are modelling with ISTC is most analagous to
>>>> our work rather than our expression, but they may (likely) define that
>>>> thing (which we call work) differently than we do. Or maybe James is
>>>> right and it's most analagous to our expression. It is confusing.
>>>>
>>>>
>>> It IS confusing, but my understanding is the same as Jim's - ISTC
>>> identifies a text qua text. Translations are considered
>>> "derivations" and get a different ISTC from the original. (Whether
>>> or not something hangs these together I'm not clear on at the
>>> moment, but the documentation may say.) So that would make them
>>> expressions. However, if we could link together a bunch of
>>> expressions, then we would have a kind of de facto definition of a
>>> Work, in the FrBR sense.
>>>
>>> kc
>>>
>>>
>>>
>>>
Received on Tue Oct 27 2009 - 15:13:47 EDT