From: Sebastian R. <seb...@ou...> - 2012-04-18 01:17:50
|
At the TEI members meeting last year, Oyvind and I were tasked with drafting the specification of an <object> element for the TEI. We duly met in December and did this. You can see the documentation for the result at http://tei.svn.sourceforge.net/viewvc/tei/trunk/Documents/Object/object.doc.html?revision=10008 We should have done more on this, before the recent TEI Technical Council meeting, but we let it slip a bit. But now is the chance for everyone on this list to look at the specification/examples above and * comment * suggest better/more examples * offer prose for the Guidelines to accompany this Thoughts very welcome… -- Sebastian Rahtz |
From: Øyvind E. <oyv...@il...> - 2012-04-20 13:32:07
|
I am sorry about this delay, for which I have a major responsibility. Still, it is great to see what Sebastian has come up with based on our discussions. As for the delay, I am not too worried about it, as I no masses of people screaming to get their object element. Still, I fully agree that we should finish it sooner rather than later. I agree with Sebastian that we may need some better examples. Or are the list members happy with the examples already there? Regards, Øyvind Den 18. apr. 2012 kl. 03:17 skrev Sebastian Rahtz: > At the TEI members meeting last year, Oyvind and I were tasked with drafting the specification > of an <object> element for the TEI. We duly met in December and did this. You can see the > documentation for the result at > http://tei.svn.sourceforge.net/viewvc/tei/trunk/Documents/Object/object.doc.html?revision=10008 > > We should have done more on this, before the recent TEI Technical Council > meeting, but we let it slip a bit. But now is the chance for everyone on this > list to look at the specification/examples above and > > * comment > * suggest better/more examples > * offer prose for the Guidelines to accompany this > > Thoughts very welcome… > > -- > > Sebastian Rahtz > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________ > Tei-ontology-sig mailing list > Tei...@li... > https://lists.sourceforge.net/lists/listinfo/tei-ontology-sig |
From: Sebastian R. <seb...@ou...> - 2012-04-20 13:38:33
|
What would really help would be someone writing paragraphs of prose to Go in the Guidelines chapters. If someone other than Oyvind or I wrote that, it would be a useful test of shared understanding. Sent from my iPad >> >> > |
From: Torsten S. <sch...@ha...> - 2012-04-23 08:49:48
|
Dear all, > As for the delay, I am not too worried about it, as I no masses of people screaming to get their object element. Still, I fully agree that we should finish it sooner rather than later. I agree with Sebastian that we may need some better examples. Or are the list members happy with the examples already there? although I haven't participated in the SIG meeting in Würzburg (being busy with manuscripts), I have a very basic question: Why would we need a structure with elements as presented in the examples? We already have elements in the msdescription module which are very similar to the ones presented here and indeed we've been screaming for a long time for the widening of semantics of these msdescription elements to fit *all* objects. And after all, the <object> element contains *a description* of the object such as <person> contains *a description* of certain aspects concerning a person? (The *object itself* would be represented by the whole TEI document, including facsimile etc.) (I suppose you can see the similarity of the elements used to msDesc elements.) Take these examples: <object xml:id="rcgrindstone"> <label>Tool</label> <note>Actually, it is the combination of wheel and grindstone which makes a <soCalled>Machine</soCalled> which Crusoe uses to sharpen his tools.</note> <bibl>chapter 3, April 3rd</bibl> </object> could be: <object xml:id="rcgrindstone"> <objectIdentifier> <label>Tool</label> </objectIdentifier> <head> <note>Actually, it is the combination of wheel and grindstone which makes a <soCalled>Machine</soCalled> which Crusoe uses to sharpen his tools.</note> </head> <additional> <listBibl> <bibl>chapter 3, April 3rd</bibl> </listBibl> </additional> </object> It might be worth to discuss another element giving the general description of an object like the <note> present here, instead of wrapping it up in <head>. Another example: [referring to the third example: Excalibur] <object xml:id="EXCALIBUR"> <objectIdentifier> <label>Mythical sword</label> <objectName>Excalibur</objectName> <objectName xml:lang="cy">Caledfwlch</objectName> </objectIdentifier> <physDesc> <objectDesc form="sword"> <p>Sword</p> </objectDesc> </physDesc> <note> <objectName>Excalibur</objectName> is the legendary sword of <persName ref="#ARTHUR">King Arthur</persName>, sometimes attributed with magical powers or associated with the rightful sovereignty of <placeName>Great Britain</placeName>. Sometimes Excalibur and the <rs type="object" ref="#SwordinStone">Sword in the Stone</rs> (the proof of <persName ref="#ARTHUR">Arthur</persName>'s lineage) are said to be the same weapon, but in most versions they are considered separate. The sword was associated with the Arthurian legend very early. In Welsh, the sword is called <objectName xml:lang="cy">Caledfwlch</objectName>. </note> <additional> <listBibl> <bibl> <ptr target="http://en.wikipedia.org/wiki/Excalibur"/> </bibl> </listBibl> </additional> </object> <listRelation> <relation name="owned" active="#ARTHUR" passive="#EXC"/> </listRelation> To sum up: I think we already have elements with similar semantics that I would like to see replaced with the more general elements for objects of all kind: - msName = objectName - object = msDesc - event/@type="start" = origDate (or even origDate to be replaced?) - trait/@type="Fabric" = origPlace - trait/@type="Technique" = to be invented? (objectDesc/layoutDesc? decoDesc?) Curious, best, Torsten -- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de *neu: Handschriftendatenbank* http://diglib.hab.de/?db=mss http://www.hab.de/forschung/projekte/europeana-regia.htm |
From: Sebastian R. <seb...@ou...> - 2012-04-23 12:33:18
|
That is an interesting observation, Torsten. It honestly had never occurred to me to think that msDesc is a model for a generic objectDesc. I was simply following the other model of place/person/organisation. But you could argue that all these follow the same model too. I fear we have a fork in the TEI: the place/person stuff went in with a particular mindset, leaving msDesc isolated in its own model, dictated by the very specific and hidebound views of the manuscript crowd.[1] I wonder how to proceed? what do others think? once presented, your alternative is attractive. [1] you can see I have a somewhat jaundiced view of the MSS stuff :-} -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 Sólo le pido a Dios que el futuro no me sea indiferente |
From: Syd B. <Syd_Bauman@Brown.edu> - 2012-04-23 15:13:21
|
I think, since we're not in a rush, it's worth some time to think seriously about folding <msDesc> and <object> into something that maintains the current expresivity of <msDesc>, but also permits description of other objects. And in some stretch, Sebastian, <msDesc> is not so unlike <person> (et. al). It is a structured description which has a set of manuscript-specific (as opposed to person-specific) elements which make use of existing TEI elements where reasonable, and which provide an escape hatch of very generic elements that can be used in addition or instead of the specific ones. It's just that in <msDesc> the very generic elements aren't as nice as the <state>, <trait>, and <event> of <person>. One can also quickly see the advantage of having a set of <relation>s available when you have a catalog of objects to describe. > That is an interesting observation, Torsten. It honestly had never > occurred to me to think that msDesc is a model for a generic > objectDesc. I was simply following the other model of > place/person/organisation. But you could argue that all these > follow the same model too. > > I fear we have a fork in the TEI: the place/person stuff went in > with a particular mindset, leaving msDesc isolated in its own > model, dictated by the very specific and hidebound views of the > manuscript crowd.[1] > > I wonder how to proceed? what do others think? once presented, your > alternative is attractive. > > [1] you can see I have a somewhat jaundiced view of the MSS stuff :-} |
From: Sebastian R. <seb...@ou...> - 2012-04-23 16:14:17
|
On 23 Apr 2012, at 14:08, Syd Bauman wrote: > And in some stretch, Sebastian, <msDesc> is not so unlike <person> > (et. al). yes, I agree. > It is a structured description which has a set of > manuscript-specific (as opposed to person-specific) elements which > make use of existing TEI elements where reasonable, and which provide > an escape hatch of very generic elements that can be used in addition > or instead of the specific ones. It's just that in <msDesc> the very > generic elements aren't as nice as the <state>, <trait>, and <event> > of <person>. all true. both forks (msDesc vs person/place/org) have good features. So you suggest that instead of perpetuating the person/place/org system into object, we should set about defining the middle ground merge of the best parts of both schemes, with expectation that one day all of ms/person/place/object/org fall into a common pattern. that would be a good aim. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 Sólo le pido a Dios que el futuro no me sea indiferente |
From: Sebastian R. <seb...@ou...> - 2012-04-24 08:49:11
|
On 24 Apr 2012, at 09:12, Christian-Emil Ore wrote: > On observation was that the manuscript module is simply a specialisation of a general module for the description of physical object. This is the motivation for introducing the Object -element. One should go through the manuscript module and introduce generalised elements for elements like Contents for msContents or use elements like objectDesc as they are. one of the practical problems is that it means simultaneously revising existing descriptions. so objectDesc/@form is defined as "a short project-specific name identifying the physical form of the carrier, for example as a codex, roll, fragment, partial leaf, cutting etc." and that is just the tip of the iceberg. Yes, MS module is conceptually capable of being revised into an Object module, but the route of imitating place/person/org instead meant much less work and disruption :-{ -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 Sólo le pido a Dios que el futuro no me sea indiferente |
From: Christian-Emil O. <c.e...@il...> - 2012-04-24 11:37:28
|
Hmm If I got it right: You prefer to define object similar to place, person/org, event and use the generalized desc-element instead of a modified objectDesc. If this is correct, I see your point and I will support your proposal. It is not optimal that the msDesc was included in the way it was - history is history. Chr-Emil On 24.04.2012 10:48, Sebastian Rahtz wrote: > > On 24 Apr 2012, at 09:12, Christian-Emil Ore wrote: > >> On observation was that the manuscript module is simply a specialisation of a general module for the description of physical object. This is the motivation for introducing the Object -element. One should go through the manuscript module and introduce generalised elements for elements like Contents for msContents or use elements like objectDesc as they are. > > > one of the practical problems is that it means simultaneously revising existing descriptions. so > objectDesc/@form is defined as > "a short project-specific name identifying the physical form of the carrier, for example as a codex, roll, fragment, partial leaf, cutting etc." > and that is just the tip of the iceberg. Yes, MS module is conceptually capable of being revised into an Object module, but the route of > imitating place/person/org instead meant much less work and disruption :-{ > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > Sólo le pido a Dios > que el futuro no me sea indiferente > |
From: Christian-Emil O. <c.e...@il...> - 2012-04-23 09:07:33
|
I will try write some mundane examples. The object element should be related to the msDesc and especially to the objDesc. In fact the objDesc element should/could be used in the description of the object element an not confined(?) to msDesc. Chr-Emil On 20.04.2012 14:30, Øyvind Eide wrote: > I am sorry about this delay, for which I have a major responsibility. Still, it is great to see what Sebastian has come up with based on our discussions. > > As for the delay, I am not too worried about it, as I no masses of people screaming to get their object element. Still, I fully agree that we should finish it sooner rather than later. I agree with Sebastian that we may need some better examples. Or are the list members happy with the examples already there? > > > Regards, > > Øyvind > > Den 18. apr. 2012 kl. 03:17 skrev Sebastian Rahtz: > >> At the TEI members meeting last year, Oyvind and I were tasked with drafting the specification >> of an<object> element for the TEI. We duly met in December and did this. You can see the >> documentation for the result at >> http://tei.svn.sourceforge.net/viewvc/tei/trunk/Documents/Object/object.doc.html?revision=10008 >> >> We should have done more on this, before the recent TEI Technical Council >> meeting, but we let it slip a bit. But now is the chance for everyone on this >> list to look at the specification/examples above and >> >> * comment >> * suggest better/more examples >> * offer prose for the Guidelines to accompany this >> >> Thoughts very welcome… >> >> -- >> >> Sebastian Rahtz >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________ >> Tei-ontology-sig mailing list >> Tei...@li... >> https://lists.sourceforge.net/lists/listinfo/tei-ontology-sig > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Tei-ontology-sig mailing list > Tei...@li... > https://lists.sourceforge.net/lists/listinfo/tei-ontology-sig |
From: Torsten S. <sch...@ha...> - 2012-04-23 12:53:21
|
Dear Sebastian, > That is an interesting observation, Torsten. It honestly had never occurred to me to think > that msDesc is a model for a generic objectDesc. but we've been talking about tboDesc since at least 2008. Only that objectDesc is even wider than tboDesc. ;-) (And the element name objectDesc is in use already!) I always tried to ignore the "ms" part in all the elements of msdescription and think of that module as a generic way of describing objects. You will always want to identify, describe physical attributes, content and history of an object, won't you? > I was simply following the other model of place/person/organisation. > But you could argue that all these follow the same model too. > > I fear we have a fork in the TEI: the place/person stuff went in with a particular mindset, > leaving msDesc isolated in its own model, dictated by the very specific > and hidebound views of the manuscript crowd.[1] My fear would be our fear not to break existing documents and to "over-distinguish" between "representation of things" in opposite to "description of things" which -as I said- I think is not exactly possible. And that the approach of the SIG might have been taken to far to adapt to something completely different. > I wonder how to proceed? what do others think? once presented, > your alternative is attractive. > > [1] you can see I have a somewhat jaundiced view of the MSS stuff :-} Which means what? "To-special-for-everyone-to-make-everyone-happy"? "To-deep-to-handle-properly"? (with your stylesheets?) Best, Torsten -- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de *neu: Handschriftendatenbank* http://diglib.hab.de/?db=mss http://www.hab.de/forschung/projekte/europeana-regia.htm |
From: Sebastian R. <seb...@ou...> - 2012-04-23 13:31:47
|
On 23 Apr 2012, at 13:53, Torsten Schassan wrote: > > but we've been talking about tboDesc since at least 2008. Only that objectDesc is even wider than tboDesc. ;-) yes, I just never made the connection…. >> [1] you can see I have a somewhat jaundiced view of the MSS stuff :-} > > Which means what? "To-special-for-everyone-to-make-everyone-happy"? "To-deep-to-handle-properly"? (with your stylesheets?) > what bothers me is the mixture of over prescriptive content models and ms-specific names mixed with very vague content models (a <p>). and some wheel reinvention. It always struck me as typical of the TEI, using one model to cover both database dumps, and transcriptions of existing descriptions. But no matter, its just my prejudice. -- Stormageddon Rahtz Head of Information and Support Group Oxford University Computing Services 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 Sólo le pido a Dios que el futuro no me sea indiferente |
From: Peter S. <st...@ed...> - 2012-04-23 14:56:19
|
Dear Torsten, I admit I'd rather like the object element to stay with the ontological guys then the codex guys. And I think you can make a distinction between representation and description. Clearly the person element holds a *description* of a person in text format, while the TEI element holds a *representation* of a *text* along with meta data about the (physical) text bearing object and meta data about textual phenomena etc. Hence object is an ontological super class (CIDOC CRM E77 Persistent item?) for man made things (texts, battleships) as well as persons At least that's been my understanding. But maybe I'm missing your point?! All the best Peter Am 23.04.2012 um 14:53 schrieb Torsten Schassan: > My fear would be our fear not to break existing documents and to > "over-distinguish" between "representation of things" in opposite to > "description of things" which -as I said- I think is not exactly possible. > And that the approach of the SIG might have been taken to far to adapt > to something completely different. |
From: Torsten S. <sch...@ha...> - 2012-04-24 07:32:45
|
Dear Peter, dear all, > I admit I'd rather like the object element to stay with the ontological guys then the codex guys. > And I think you can make a distinction between representation and description. Clearly the person element holds a *description* of a person in text format, while the TEI element holds a *representation* of a *text* along with meta data about the (physical) text bearing object and meta data about textual phenomena etc. Hence object is an ontological super class (CIDOC CRM E77 Persistent item?) for man made things (texts, battleships) as well as persons > At least that's been my understanding. But maybe I'm missing your point?! you're right to think of representation and description as two different things. My idea (and approach) is now to examine the way we represent and describe the object and it occurs to me that we can't really distinguish between the two. Especially I don't understand why we want to invent a whole new set of elements or new structures to represent the object if we already have elements and quite elaborate structures in the msdescription module to do so. That is why I think we at least should try to do both in similar ways, using the same elements and structures. An analogy: The manuscript description too has two meanings: For one it is metadata about an object, the manuscript. We use to store the description in a <msDesc> in teiHeader/fileDesc/sourceDesc. On the other hand it is *the data* of the manuscript catalogue which compiles several ms descriptions at a time, thus it is part of the text (TEI/text). *But*: we use to store both texts in the same structure, using the expressive and semantic rich markup of msdescription. If this thinking lead to a generalisation of the meaning of msDesc and other msXxx elements even better. As Sebastian has asked, how to proceed from here? Maybe a general decision about this very basic issue (have one or two structures) has to come first? Best, Torsten -- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de *neu: Handschriftendatenbank* http://diglib.hab.de/?db=mss http://www.hab.de/forschung/projekte/europeana-regia.htm |
From: Peter S. <st...@ed...> - 2012-04-23 15:34:29
|
Just a few comments regarding the examples: #3: the xml:id is "EXCALIBUR" but the relation references "EXC" #4: I'd add objectName="HMS Royal George" after label. #6: Why is "machine" tagged as an objectName rather than rs? I'd say "Excalibur", "HMS Royal George" etc. are names but not the term "machine" ... #2+5: The various idnos are a mystery to me. Maybe one can find something more self-explanatory? Many thanks for all the work Peter Am 18.04.2012 um 03:17 schrieb Sebastian Rahtz: > At the TEI members meeting last year, Oyvind and I were tasked with drafting the specification > of an <object> element for the TEI. We duly met in December and did this. You can see the > documentation for the result at > http://tei.svn.sourceforge.net/viewvc/tei/trunk/Documents/Object/object.doc.html?revision=10008 > > We should have done more on this, before the recent TEI Technical Council > meeting, but we let it slip a bit. But now is the chance for everyone on this > list to look at the specification/examples above and > > * comment > * suggest better/more examples > * offer prose for the Guidelines to accompany this > > Thoughts very welcome… > > -- > > Sebastian Rahtz |
From: Christian-Emil O. <c.e...@il...> - 2012-04-24 08:12:50
|
The manuscript chapter in TEI guidelines is, correct me if I am wrong, the reesult of the work in the Master project. The Master project had the objective to develop a xml shceme and recommendation for encoding manuscript catalogues. The work was based on the practice manifested in a series of manuscript catalogues and on practice in selected libraries and archives. In this way the work was indeed an example of practical ontological analysis. A manuscript is a physical, man made artefact, and is in this view similar to any other artefact, say a sword (not not neccessarily Excalibur). Thus, in a conceptual model there may be some specialising extensions to the general artefact model for manuscripts as it may be for paintings or fabrics. In addition the manuscript module contains elements for describing the intellectual content of a manuscript (<msContents> (manuscript contents) describes the intellectual content of a manuscript or manuscript part, either as a series of paragraphs or as a series of structured manuscript items.) If TEI had been created top down (and not as the work of more or less independent groups), my claim is that there had made a module for the description of physical objects and then any necessary specialisations for the description of manuscripts/encoding of manuscript catalogues. The msContents could have been a generalisation of a general description of intellectual work like the one we find in FRBR/FRBRoo. It was, at least my intention, in the paper given ( by Øyivind Eide and me) at DH2008 in Oulo to analyse what is missing and what is superfluous in TEI seen for a given cultural heritage ontology (CIDOC-CRM). On observation was that the manuscript module is simply a specialisation of a general module for the description of physical object. This is the motivation for introducing the Object -element. One should go through the manuscript module and introduce generalised elements for elements like Contents for msContents or use elements like objectDesc as they are. Chr-Emil On 23.04.2012 17:44, Sebastian Rahtz wrote: > > On 23 Apr 2012, at 14:08, Syd Bauman wrote: >> And in some stretch, Sebastian,<msDesc> is not so unlike<person> >> (et. al). > yes, I agree. > >> It is a structured description which has a set of >> manuscript-specific (as opposed to person-specific) elements which >> make use of existing TEI elements where reasonable, and which provide >> an escape hatch of very generic elements that can be used in addition >> or instead of the specific ones. It's just that in<msDesc> the very >> generic elements aren't as nice as the<state>,<trait>, and<event> >> of<person>. > > > all true. both forks (msDesc vs person/place/org) have good features. > > So you suggest that instead of perpetuating the person/place/org > system into object, we should set about defining the middle ground > merge of the best parts of both schemes, with expectation that one > day all of ms/person/place/object/org fall into a common pattern. that > would be a good aim. > -- > Stormageddon Rahtz > Head of Information and Support Group > Oxford University Computing Services > 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431 > > Sólo le pido a Dios > que el futuro no me sea indiferente > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Tei-ontology-sig mailing list > Tei...@li... > https://lists.sourceforge.net/lists/listinfo/tei-ontology-sig |