Menu
▾
▴
#187 new element 'objectType' (was: 'object')
closed-accepted
5
2013-12-22
2009-06-24
No
We would like a new element to encode the object-type, especially for non-codex-like text-bearing objects, which currently have to be described in an @form attribute on <objectDesc>. The new element should also allow the @ref attribute to point to a taxonomy (cf. ticket #2811234, new @form on <material>). The element <object> should be able to be a child of <support> and behave in every other way just like <material>.
Can you provide me some additional examples how it might be used? The way I'm thinking about it an 'object' is different from the @form of an object. I'm assuming that in the example on the ref page:
<support> Parchment roll with <material>silk</material> ribbons. </support>
that <object> here would surround 'Parchment roll' ?
I've no problem with it getting @ref.
I agree with James that examples are needed. It's an objectType rather than an individual object that's wanted, I assume -- so "sword" rather than "Excalibur", "sash" rather than "the sash my father wore" etc?
More eexample needed and better clarification requested
The request is for an element parallel with <material> (including the addition of @ref as discussed in 2811234). Like <material>, it would be a child of <support>. It would enable smaller granularity of description than is enabled by using @form on <objectDesc>. The example of <support> from the guidelines:
<objectDesc form="roll">
<supportDesc>
<support> Parchment roll with <material>silk</material> ribbons.
</support>
</supportDesc>
</objectDesc>
Would be:
<objectDesc>
<supportDesc>
<support> <material>Parchment<material> <object>roll<object> with <material>silk</material> <object>ribbons<object>.
</support>
</supportDesc>
</objectDesc>
cf. 2811234: @ref would be available on both <material> and <object>, so the instances in the <support> prose could point to a list existing elsewhere.
In general, I think I'm in favor of <object> with ref= on both <object> and <support> (which perhaps should be <objectType> and <madeOf>). This would permit
_<support>
___<object>roll</object>
___<material>parchment</material>
_</support>
somewhat different than
_<support>
___<object>roll</object>
___<material>paper towel</material>
_</support>
But the discussion brings up a potential problem. Again playing devil’s advocate: doesn’t this example (from the <support> and <supportDesc> tagdocs) imply that there is writing on the silk ribbon?
I fear I don't understand what Syd's example is trying to convey, unless it's that a "paper towel" is an object rather than a kind of material (one might say "paper towelling" for the latter, I suppose). More significantly though, I am still not clear as to what an "object" is meant to be. If it's the particular object being described, then it's the same as <support>. If it's the general category to which that object belongs, then it's the @form on <support> isn't it? More examples would certainly help clarify this.
More examples coming, but yes, in a sense this is an attempt to enable further constraint and linking of the object-type than support/@form currently allows.
I don't think hte example provided by "nobody" in the logic of the TEI modularisation: I would expect multiple <object>s inside <objectDesc> and within these <supportDesc> with possible multiple <supports>!
[Whenever we come across a <...Desc> in TEI, the same element is used as child! ]
The @form would have to be moved to the <object> then?
<objectDesc>
<object form="roll">
<supportDesc>
<support> <material>Parchment<material> <term>roll<term></support>
</supportDesc>
</object>
<object form="ribbon">
<supportDesc>
<support>with <material>silk</material> <term>ribbons<term></support>
</supportDesc>
</object>
</objectDesc>
The Council members appointed to "nuncle" this feature request and make a proposal for TEI Council to take forward (Brett B, Gabriel B, Elena P, Dot P) have come to the following decision:
Our conclusion is that an tei:objectType (or similarly named) element serves a perfectly analogous role to the <material> element; that is it is more flexible way to handle descriptions of objects in running prose (usually in the section), which allows multiple objects for a single text, and pointing by means of an @ref to either an external authority list/taxonomy, or an internal set of terms (which Elli Mylonas stores in tei:keywords/taxonomy, I believe--see her DH2010 poster).
The objection that this duplicates tei:objectDesc/@form is not convincing (so does <material> duplicate tei:supportDesc/@material); both elements provide more flexibility and control over the encoding of this information. This element does seem to be needed, as evidenced by the fact that EpiDoc have been using tei:rs[@type='object'] alongside tei:material for years now and Elli's USEP project is using tei:seg[@type='object'] alongside tei:seg[@type='material'] for at least as long.
Lou prefers the element name tei:objectType to the shorter tei:object because we're talking about values like "sword" (types) rather than like "Excalibur" (specific objects). We are less uncomfortable with the semantics of "object" being stretched to refer to a class of object, but there have been two further arguments in favour of the more explicit naming:
(1) Tosten Schassan (below) demonstrates the possible misunderstanding associated with the name "object" in the context of "support" and "supportDesc".
(2) Oyvind Eide (who proposed several new elements for encoding ontological information in LLC 24.2, p. 171, including "physicalObject"), verbally suggested to me that the important thing about this proposal is to make sure any new element is not named in such a way that it might be interpreted to mean something that would be used outside of its strict context in the MS Description module. (It may also be worth explicitly asking Oyvind and Christian-Emil Ore to comment on this proposal before Council decides to act upon it.)
We therefore propose that Council create a new element tei:objectType, which have the same content model and attribute classes as tei:material.
I'm happy to help compose the description of this element for the elements list and general guidelines prose.
We have discussed this proposal a little bit on the TEI Ontologies SIG list. There were some concerns about the name, as noted in my comment referred by gabrielbodard on 2010-12-17 17:45:46 CET.
As far as I can see, the choice of the name objectType answers to these concerns, because it clarifies that the element is meant for things like "tombstone", not things like "the Rosetta Stone". Please correct me if this understanding is not correct.
The discussion about possible elements for things like "the Rosetta Stone" or "Excalibur" is then differerent from this current discussion.
The element tei:objectType was created in 2010.
If oeide and co want to propose the new element tei:object, they should submit a new feature request proposing this.