If it's inherently stand-off, then it shouldn't matter *where* it 
appears, surely? There is no "logical" place for it, neither in the 
`<list*>` nor anywhere else. It should either be really stand-off, and 
therefore have a dedicated place to live which is not a list* or 
anything else connected to its context, or it should be allowed in many 
more contexts. (Why not, for example, allow places and relations to 
interleave in a listPlace, rather than insisting all the former precede 
all the latter?)


On 21/08/2015 17:26, Martin Holmes wrote:
> I would argue that <relation> is inherently a stand-off element, because
> it links multiple components. Even at its simplest, it links two
> components, so you would have to decide to put it inside one <place> or
> the other <place>, so it wouldn't be ideally placed for one of them. To
> place it in the <list*> among whose components it's defining relations
> seems the logical thing to me.
> Cheers,
> Martin
> On 15-08-21 09:20 AM, BODARD Gabriel wrote:
>> Unfortunately (?) there is a hack to this, which is that you can embed
>> the `<relation>` elements in a listBibl, within each place, giving the
>> convenience desired by the original questioner (and by most people
>> encoding gazetteers or personographies involving relationships, I
>> imagine).
>> Unsurprisingly therefore, I'm going to argue the content model of
>> `<listPlace>` is "incorrect{ly}". :)
>> On 21/08/2015 16:54, Syd Bauman wrote:
>>> Very quickly ...
>>>> ... which has some hierarchical relationship with other places in
>>>> the list ...
>>> If the relationship is hierarchical, there may be a better way to
>>> represent it. E.g., the fact that my home town (Rehoboth) is part of
>>> Bristol County which is part of Massachusetts which is part of the
>>> United States might be represented with something like one of the
>>> following.
>>>          <place type="town" xml:id="town_Rehoboth_long-hand">
>>>            <placeName>Rehoboth</placeName>
>>>            <location>
>>>              <region type="county">Bristol</region>
>>>              <region type="state">Massachusetts</region>
>>>              <country>United States of America</country>
>>>            </location>
>>>          </place>
>>>          <!-- OR -->
>>>          <place type="town" xml:id="town_Rehoboth_using_refs">
>>>            <placeName>Rehoboth</placeName>
>>>            <location>
>>>              <region ref="#county_Bristol"/>
>>>              <region ref="#state_MA"/>
>>>              <country ref="#country_USA"/>
>>>            </location>
>>>          </place>
>>> Yes, it's a bit more encoding, but depending on what you're trying to
>>> do, the former is *much* easier to process. (And the latter is
>>> probably easier, too.)
>>> Anyway, the content model for <listPlace> is (rightly or wrongly):
>>>     (
>>>        model.headLike*,
>>>        ( model.placeLike | listPlace )+,
>>>        ( relation | listRelation )*
>>>     )
>>> which is to say "any number of <head> or things like it, followed by
>>> one or more <place> or <listPlace>, followed by any number of
>>> <relation> or <listRelation>". Thus, all the relationship information
>>> goes *after* the list of places.
>>>> I am making a <placeList> which involves the inclusion of multiple
>>>> types of places, all of which has some hierarchical relationship
>>>> with other places in the list. To mark this relationship, the most
>>>> rational strategy in the TEI element set is of course <relation>,
>>>> which according to the guidelines, it is allowed to occur within a
>>>> <listPlace>.
>>>> Ideally I would like to put a relation element within each <place>
>>>> entry block so as to keep all of the information all in the same
>>>> place for the entire contents of the list, but for some reason that
>>>> is not allowed….
>>>> So the next most acceptable thing is to place the <relation>'s in
>>>> somewhere near (either before or after) the related elements so the
>>>> encoding process and human readability of the document is easier…
>>>> e.g.
>>>>              <place n="681" xml:id="Öst.">
>>>>                 <placeName xml:lang="de">Österreich</placeName>
>>>>                 <placeName xml:lang="de" full="abb">Öst.</placeName>
>>>>                 <location>
>>>>                    <geo corresp="#gis_region_id-862"/>
>>>>                 </location>
>>>>              </place>
>>>>              <relation name="vaterregion" active="#Öst." passive="#Kä
>>>> #OÖ #Bgl. #NÖ #Sa. #St. #Tir. #W. #Vlbg."/>
>>>>              <!--  administrative regions within country -->
>>>>             <place n="181" xml:id="OÖ">
>>>>                <placeName xml:lang="de">Oberösterreich</placeName>
>>>>                <placeName xml:lang="de" full="abb">OÖ</placeName>
>>>>                <location>
>>>>                   <geo corresp="#gis_region_id-735"/>
>>>>                </location>
>>>>             </place>
>>>>              <place n="101" xml:id="Kä">
>>>>                 <placeName xml:lang="de">Kärnten</placeName>
>>>>                 <placeName xml:lang="de" full="abb">Kä</placeName>
>>>>                 <location>
>>>>                    <geo corresp="#gis_region_id-708"/>
>>>>                 </location>
>>>>              </place>
>>>>        ….
>>>> However, when placed in multiple, non-adjacent places as described
>>>> above the following error message is raised (in Oxygen):
>>>> E [Jing] element "place" not allowed here; expected the element
>>>> end-tag or element "listRelation" or "relation"
>>>> I have noticed this also happens where trying to do the same thing
>>>> (which also should be allowed according to the guidelines) within
>>>> <listPerson> as well.
>>>>> Is this supposed to happen or is there something wrong with
>>>>> Oxygen?
>>>>>> If this is not a glitch, can anyone explain to me the reasoning
>>>>>> behind requiring that all occurrences of <relation> be adjacent
>>>>>> in these contexts?

Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
Boris Karloff Building
26-29 Drury Lane
London WC2B 5RL

Email: [log in to unmask]
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980