[MEI-L] Ontologies (was FRBR in MEI)

David Meredith dave at create.aau.dk
Thu Nov 22 21:37:47 CET 2012 

I guess my point was that having a separate dedicated, "hard-coded"
property for each website that refers to the object seems a bit
inflexible. It would make more sense to me if one could associate with the
object a list of <site, id> pairs, where the site could be a URL and the
id would be the relevant id of the resource on that site. But I haven't
studied this ontology in depth, so I may be missing the point...

Dave

On 22/11/2012 19:11, "Benjamin Wolff Bohl" <bohl at edirom.de> wrote:

>Hi Dave,
>thanks for contributing to this discussion.
>
>> "musicbrainz_guid"
>> "amazon_asin"
>> "myspace"
>the musicbrainz_guid and amazon_asin are boh identifiers that can be
>entered into MEI as depending on what it means for your project, e.g. as
>identifier as @dbkey or the like.
>A similar solution can be found in an ontology.
>>
>> So is the idea that a new property has to be added each time someone
>> builds a new electronic catalogue? Doesn't seem particularly scaleable.
>Depending on your project you might want to add these identifiers to
>your MEI file or not. So I guess it is scalable to your needs, or am I
>getting this wrong?
>> Or
>> are there just going to be some arbitrarily privileged catalogues that
>> have associated properties?
>Can you explain this question a little more? Which catalogs are you
>meaning for example and where would their properties be associated?
>
>Cheers, Benjamin
>
>>
>> - Dave Meredith, Aalborg
>>   
>>
>>
>> On 21/11/2012 10:11, "Tim Crawford" <t.crawford at gold.ac.uk> wrote:
>>
>>> Dear All,
>>>
>>> While I have absolutely no wish to get further involved in this
>>> fascinating discussion, it strikes me that yes, indeed, much of what
>>> Benjamin is talking about may be handled better by a music ontology.
>>>
>>> And such a thing - the Music Ontology - has now reached an advanced
>>> state of development by researchers at the BBC and elsewhere over a
>>> number of years. For details and specification, see:
>>>
>>>      http://musicontology.com/
>>>
>>> I'm not sure this alone (or even the entire apparatus of the Semantic
>>> Web) will solve all the problem cases you might encounter or devise,
>>> but at least it might relieve some of the pressure caused by a desire
>>> to encode *everything* about a musical work within MEI ...
>>>
>>> Keep up the great work!
>>>
>>> Tim Crawford, London
>>>
>>> On 21 Nov 2012, at 08:24, Benjamin Wolff Bohl wrote:
>>>
>>>> Hi there,
>>>> first thanks to Axel for sorting out that FRBR is for bibliographic
>>>> items and thus performances, that we have nothing more of than the
>>>> knowledge it happened are out of scope.
>>>> I've somehow been thinking too much towards somthing like a music
>>>> ontology.
>>>> Moreover the idea of having a hierarchy in FRBR might have mislead
>>>> me, prooving Peter's earlier mentioned concerns regarding this true.
>>>>
>>>> Nevertheless we still got the recordings to deal with!
>>>> So Johannes, let's continue to disagree ;-)
>>>>
>>>>> Hi Benni,
>>>>>
>>>>> I hope I got one of your last mails wrong (in this regard), but
>>>>> just in case I didn't: By no means I wanted to keep you from
>>>>> commenting on this (or other) thread(s), as your comments are
>>>>> extremely valuable and helpful ­ even if I sometimes disagree. If I
>>>>> offended you somehow, that wasn't my intention, and I want to
>>>>> apologize for it.
>>>>>
>>>>> That being said, I may continue to disagree ;-) Actually, I don't
>>>>> think we're that far away. The one thing you seem to get wrong
>>>>> though is the process from expression to manifestation, which is in
>>>>> no case trivial and a mere technological step without artistic
>>>>> contribution. When you consider the efforts necessary to engrave a
>>>>> piece of music, or the work on the preparation of the WeGA scores
>>>>> we see every day, you will agree that even in the graphical domain,
>>>>> this step is indeed highly artistic and involves a whole bunch of
>>>>> people with different expertise. I agree that the workflows for
>>>>> making recordings are different, but both things seem to be
>>>>> comparable from this perspective, don't you think?
>>>> I neither think that we are too far away from each other now. And I
>>>> never wanted to say that the transiton from expression to
>>>> manifestation was a mere technical, but maybe I should have
>>>> explained a little more what my initial graphic was all about with
>>>> the recordings, as by no means it would involve a mere technical
>>>> step. Beginning from the way the recording engineer set up his
>>>> microphones and what he did on his audio desk, across quite a couple
>>>> of steps involving editing (cutting, rather technical but
>>>> nevertheless with artistic implications), mixing (very artistic) and
>>>> mastering(as artistic as technical), that all would result in
>>>> archive material quite a lot of intellectual/artistic work is
>>>> involved in a record(ing).
>>>>
>>>> I'll have a try on this:
>>>> WORK - examination -> edition (e1) ------------- engraving -> print
>>>> run (m1) -printing -> print copy (i1)
>>>>
>>>> If you have the above, and try to get a parallel idea on the way to
>>>> the copy of a record on your shelf (i2):
>>>> (1) What will be expression?
>>>> (2) What will be manifestation?
>>>> (3) Is one stream of e-m-i this sufficient?
>>>>
>>>> WORK - examination -> artist's inpterpretation (e2) - -
>>>>>               ?             -> record copy (i2)
>>>> or
>>>>
>>>> WORK - recording   ->          ?          - mastering -> label's
>>>> press run -pressing (m2) -> record copy (i2)
>>>>
>>>> Maybe let's try to fill this with one of Don's "Greatful" examples:
>>>> The Song "Truckin" has been released Nov 1 1970 on the album
>>>> "American Beauty" and as a single. The album was recorded in AUG-
>>>> SEP 1970, although it might be the single version was recorded in
>>>> SEP or maybe this specific song was recorded in SEP.
>>>>
>>>> Truckin (w1) --> 1970-08 to 1970-09 Session Tapes (e2) --> 1970-11-1
>>>> Warner bros. release of "American Beauty" album (m2) --> record copy
>>>> (i2)
>>>> Truckin (w1) --> 1970-08 to 1970-09 Session Tapes (e3) --> 1970-11-1
>>>> Warner bros. release of "Truckin" single (m3) --> record copy (i3)
>>>>
>>>> But the single version and album version differ quite a lot, album
>>>> length 5:09 and single 3:13 so we should specify a little more.
>>>>
>>>> Truckin (w1) --> 1970-08 to 1970-09 Session Tape album-verison (e2)
>>>> --> 1970-11-1 Warner bros. release of "American Beauty" album (m2) --
>>>>> record copy (i2)
>>>> Truckin (w1) --> 1970-08 to 1970-09 Session Tape single-version (e3)
>>>> --> 1970-11-1 Warner bros. release of "Truckin" single (m3) -->
>>>> record copy (i3)
>>>>
>>>> A little complication: the single version was not recorded but taken
>>>> from the album version and edited down from 5 to 3 minutes
>>>> nevertheless it is a own expression, but it hints us twords some
>>>> items that might reside in an archives shelf, namely:
>>>> - session tapes : the tapes from the recording session (potentially
>>>> multi-track)
>>>> - edit tapes : the tapes where all the nice parts from the session
>>>> tapes were cut together to make up the material for the work
>>>> (potentially multi-track)
>>>> - mix tapes : a stereo mix version including lots of additional
>>>> features like for example delay effects etc. resembling the final
>>>> version
>>>> - master tapes : an acoustically slightly reshaped version of the
>>>> mix tape version in order to fit the technical limitations of a
>>>> certain target medium like vinyl and some intellectual work to
>>>> smoothen the mix (e.g. making all songs on a record sound similar)
>>>>
>>>> If they are relevant for my MEI file, they should go into <source>,
>>>> but where should these go in FRBR?
>>>> Maybe they should all be separate expressions with strong relations
>>>> to each other?
>>>> So actually the only one in the direct same "FRBR hierarchy" would
>>>> be the master tape?
>>>>
>>>> Truckin (w1) --> 1970-09-XX "Truckin" Master Tape (e3) --> 1970-11-1
>>>> Warner bros. release of "Truckin" single (m3) --> record copy (i3)
>>>>
>>>> If I don't know about all the tapes I might just put?
>>>> Truckin (w1) --> 1970-08 to 1970-09 recordings --> 1970-11-1 Warner
>>>> bros. release of "Truckin" single (m3) --> record copy (i3)
>>>>
>>>> or?
>>>>
>>>> Truckin (w1) --> 1970 Version (e3)--> 1970-11-1 Warner bros. release
>>>> of "Truckin" single (m3) --> record copy (i3)
>>>>
>>>> What do you think, is there still a problem?
>>>> Is there anything interesting for you in the above?
>>>>
>>>>> Besides that, I totally agree that FRBR is not extremely
>>>>> prescriptive regarding how to model certain situations, but after
>>>>> thinking about it for some time, I (now) think that this is
>>>>> actually a benefit, as it doesn't enforce a specific setup, but
>>>>> allows projects to implement it as they see fit. So in the end, I'm
>>>>> not against your approach in general, I'm just against enforcing
>>>>> your approach. The current implementation of FRBR in MEI tries to
>>>>> keep this openness of FRBR, which I regard as a good thing. In the
>>>>> end, all of us could be wrong ;-)
>>>> I never wanted to enforce anything only to show up possibilities to
>>>> be considered when implementing FRBR or test the current
>>>> implementation against. And I think you're absolutely right that an
>>>> openness could be a benefit as we certainly will miss possible
>>>> complicated situations.
>>>>
>>>> <salutation>benjamin</salutation>
>>>>> Best,
>>>>> Johannes
>>>>>
>>>>> Am 20.11.2012 um 12:33 schrieb Axel Teich Geertinger:
>>>>>
>>>>>> Hi Benni
>>>>>>
>>>>>> Perhaps we should remember that FRBR is intended for
>>>>>> _bibliographic records_, not for descriptions of a work's
>>>>>> reception history. Thus, the premise for using FRBR is that in the
>>>>>> end we want to describe bibliographic items. Since a performance
>>>>>> itself isn't a bibliographic item, perhaps it does not have to fit
>>>>>> in? Only if it results in such an item (via manifestation), i.e. a
>>>>>> recording, it becomes truly relevant to use FRBR. The performance
>>>>>> in that case is not the primary thing we want to describe, it is
>>>>>> just the context that resulted in the recording manifestation.
>>>>>>
>>>>>> Just another 2 cents,
>>>>>> Axel
>>>>>>
>>>>>> -----Oprindelig meddelelse-----
>>>>>> Fra: mei-l-bounces at lists.uni-paderborn.de
>>>>>> [mailto:mei-l-bounces at lists.uni-paderborn.de
>>>>>> ] På vegne af Benjamin Wolff Bohl
>>>>>> Sendt: 20. november 2012 11:57
>>>>>> Til: Music Encoding Initiative
>>>>>> Emne: Re: [MEI-L] FRBR in MEI
>>>>>>
>>>>>> Hi Perry,
>>>>>> thanks for some clarifying approaches
>>>>>> further statements inline
>>>>>>
>>>>>> Am 16.11.2012 22:25, schrieb Roland, Perry (pdr4h):
>>>>>>> Random comments on the discussion so far.  Sorry if this gets long.
>>>>>>>
>>>>>>> When contemplating performances and recordings, it seems to me
>>>>>>> that people often have trouble reaching agreement on the term
>>>>>>> "sound recording".  Andrew's slides label the *expression* as
>>>>>>> "the sound recording", but others might label the *manifestation*
>>>>>>> as "the sound recording".  You might say the expression is the
>>>>>>> "act of making a recording" and the manifestation is the
>>>>>>> "recording that results".
>>>>>>>
>>>>>>> To disentangle the different uses of the term "recording", it
>>>>>>> helps me to remember that an expression is not a physical entity,
>>>>>>> but a manifestation is.  Therefore, I prefer to think of the
>>>>>>> expression as "the performance" (the non-physical thing being
>>>>>>> recorded) and the manifestation as "the recording" (the physical
>>>>>>> thing).  This fits with the way libraries have traditionally
>>>>>>> cataloged recordings, i.e., CDs, LPs, cassettes, wax cylinders, ...
>>>>>> I completely agree on that, being the reason why I used both the
>>>>>> terms recording and record with record being on the manifestation/
>>>>>> item-level and recording being rather on the expression-
>>>>>> manifestation-level. Why so? Recording has to be subordinate to
>>>>>> work after all and a recording is not just a simple physical
>>>>>> manifestation but a multistep process involving conceptual and
>>>>>> creative work done by producers and engineers.
>>>>>> So talking about a recording as only being a manifestation becomes
>>>>>> problematic as it is a intellectual process resulting in a
>>>>>> physical manifestation. That's the way I was looking on it (owed
>>>>>> to my audio engineering past) and of course it can be seen
>>>>>> differently.
>>>>>>> In any case, the FRBR document, which Axel cites, says a
>>>>>>> *performance is an expression* and a *recording is a
>>>>>>> manifestation*.
>>>>>> This is perfectly plausible when disregarding the intellectual
>>>>>> endeavour entangled with the "act of making a recording", as
>>>>>> mentioned before.
>>>>>>> The usual "waterfall" kind of diagram is explained by saying the
>>>>>>> term
>>>>>>> "work" applies to conceptual content; "expression" applies to the
>>>>>>> languages/media/versions in which the work occurs; "manifestation"
>>>>>>> applies to the formats in which each expression is available; and
>>>>>>> "item" applies to individual copies of a single format.  (Here
>>>>>>> "media"
>>>>>>> means "medium of expression", say written language as opposed to
>>>>>>> film,
>>>>>>> and "format" means physical format, as in printed book as opposed
>>>>>>> to
>>>>>>> audio CD.)
>>>>>>>
>>>>>>> Taking another tack, though, often it is easier for me to think
>>>>>>> of FRBR "from the bottom up", rather than start from the work and
>>>>>>> proceed "down" the waterfall diagram.  Using the recording
>>>>>>> example, the item is the exemplar I hold in my hand, the
>>>>>>> manifestation is all of the copies of that exemplar (or better
>>>>>>> yet, all the information shared by all those copies), the
>>>>>>> expression is the version of the work that is represented by the
>>>>>>> manifestation (e.g., Jo's nose flute + harpsichord version and
>>>>>>> the orchestral version are different expressions), and the work
>>>>>>> is an intellectual creation/idea (e.g., Bohl's op. 1, the one
>>>>>>> that goes da, da, da, daaaaaa, reeep! reeep! reeep!).
>>>>>>>
>>>>>>> Using this "bottom up" thinking helps avoid mental contortions
>>>>>>> regarding what the work is -- the work is simply the thing at the
>>>>>>> end of this mental process.  From there on, there are work-to-
>>>>>>> work relationships, so we don't have to think about whether
>>>>>>> "Romeo and Juliet", "Westside Story", and every other story about
>>>>>>> star-crossed lovers are expressions of an ur-work with its own
>>>>>>> manifestations and so on, which lead us to a different
>>>>>>> "waterfall" conclusion each time we discover a new work or
>>>>>>> expression.
>>>>>> The idea of approaching the FRBR model "from the bottom" is great.
>>>>>> And to be honest was something I did when drawing my model,
>>>>>> especially concerning the record and recording portion of it. I
>>>>>> started out from work on the top right and from the individual
>>>>>> record bottom right and tried to fill in as many steps as
>>>>>> possible, always wondering whether it be physical or conceptual.
>>>>>> Actually I had the recording in between expression and
>>>>>> manifestation in the first place, as I had the audio tape or
>>>>>> digital audio in between manifestation and item.
>>>>>> The parallel processes from a wok to an item (regardless of
>>>>>> whichever form this may have) are owed to perspective and goal.
>>>>>> When talking about graphical sources I completely agree with the
>>>>>> idea of a certain instrumentation version or the like being an
>>>>>> expression, a print run being a manifestation an individual copy
>>>>>> of which would be an item.
>>>>>>> Instead of creating separate expression-level markup for each
>>>>>>> performance, Axel treats some expressions (performances) as
>>>>>>> events related to another expression of a work (the orchestral
>>>>>>> version vs. the nose flute version).  This is fine.  As Johannes
>>>>>>> already pointed out, separate <expression> elements for the
>>>>>>> performances can be generated from the <eventList> markup, if
>>>>>>> necessary.  Conversely, there's nothing wrong with creating
>>>>>>> separate <expression> elements for each performance and relating
>>>>>>> them to other appropriate expressions and/or relating them
>>>>>>> directly to the work.  If necessary, given accurate place and
>>>>>>> date information, the <eventList> kind of markup could be created
>>>>>>> from the separate <expression> elements.  So, six of one ...
>>>>>> I can agree here, too. I only wondered if the sound wave resulting
>>>>>> from the performance was the physical item (specific performers on
>>>>>> a specific date), then consequently a series of performances by
>>>>>> conductor and orchestra would make up for the manifestation, the
>>>>>> expression then would be the concept that the conductor developed
>>>>>> studying his "source material" and making up the way he wanted the
>>>>>> composition to be realized ergo his "personal version" of the
>>>>>> piece, somewhat of a personal edition.
>>>>>> The performance material of course being an item of a certain
>>>>>> print run
>>>>>> (manifestation) of a certain edition (expression), having strong
>>>>>> relationships to all of the above.
>>>>>>> Johannes said "If there is a manuscript of the nose flute
>>>>>>> version, the information about it would be spread between the
>>>>>>> manifestation (source) and the item."  Well, maybe.  But, I think
>>>>>>> in this case it would be fine to describe the manifestation and
>>>>>>> the item in a single place (within <source> in MEI) because
>>>>>>> there's only one manifestation and one (and only one) item
>>>>>>> associated with that manifestation.  This is the traditional way
>>>>>>> manuscripts have been described, pre-FRBR.  Practically speaking,
>>>>>>> the manifesation and the item are the same thing.  But, as soon
>>>>>>> as you want to say something special about a particular *part*
>>>>>>> (as in "chunk", not performer part) of the manifestation, you
>>>>>>> have to split these up again, for example, when one section of a
>>>>>>> manuscript is located in Prague and another is in Manitoba.
>>>>>> This was the idea behind me marking/stretching the autograph from
>>>>>> expression to item.
>>>>>>
>>>>>> /benjamin
>>>>>>> This is not the case with printed material where there is
>>>>>>> *always* more than one item created from a manifestation, but it
>>>>>>> is still traditional to describe the manifestation and item as
>>>>>>> though they are the same thing.  For example, it is common to
>>>>>>> follow the manifestation's author, title, place of publication,
>>>>>>> etc. with information about the location where one can obtain an
>>>>>>> examplar of the manifestation, say, UVa Library M 296.C57 1987.
>>>>>>>
>>>>>>> Johannes also said "So if you have two more measures in a source,
>>>>>>> this
>>>>>>> source establishes a new expression in FRBR."  Again, maybe.  The
>>>>>>> FRBR
>>>>>>> report (1997, amended and corrected through 2009) says
>>>>>>>
>>>>>>> "Variations within substantially the same expression (e.g.,
>>>>>>> slight variations that can be noticed between two states of the
>>>>>>> same edition in the case of hand press production) would normally
>>>>>>> be ignored or, in specialized catalogues, be reflected as a note
>>>>>>> within the bibliographic record for the manifestation. However,
>>>>>>> for some applications of the model (e.g., early texts of rare
>>>>>>> manuscripts), each variation may be viewed as a different
>>>>>>> expression."
>>>>>>>
>>>>>>> The issue is in the determination of whether 2 things are
>>>>>>> "substantially the same expression".  As with many things, this
>>>>>>> depends on the person making the determination, there is no
>>>>>>> single correct answer.  We intend that MEI will provide the tools
>>>>>>> for accurate description using either approach.
>>>>>>>
>>>>>>> Just my 2 cents,
>>>>>>>
>>>>>>> --
>>>>>>> p.
>>>>>>>
>>>>>>> __________________________
>>>>>>> Perry Roland
>>>>>>> Music Library
>>>>>>> University of Virginia
>>>>>>> P. O. Box 400175
>>>>>>> Charlottesville, VA 22904
>>>>>>> 434-982-2702 (w)
>>>>>>> pdr4h (at) virginia (dot) edu
>>>>>>> _______________________________________________
>>>>>>> mei-l mailing list
>>>>>>> mei-l at lists.uni-paderborn.de
>>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>>
>>>>>> _______________________________________________
>>>>>> mei-l mailing list
>>>>>> mei-l at lists.uni-paderborn.de
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>>>
>>>>>> _______________________________________________
>>>>>> mei-l mailing list
>>>>>> mei-l at lists.uni-paderborn.de
>>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>> _______________________________________________
>>>>> mei-l mailing list
>>>>> mei-l at lists.uni-paderborn.de
>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>
>>>> _______________________________________________
>>>> mei-l mailing list
>>>> mei-l at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>
>>>
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
>_______________________________________________
>mei-l mailing list
>mei-l at lists.uni-paderborn.de
>https://lists.uni-paderborn.de/mailman/listinfo/mei-l

More information about the mei-l mailing list