Print

Print


Hi Jack,

Yes, please do submit a ticket for this. I take your point that the 
inconvenience of the few who write content models is soundly trumped by 
the inconvenience of encoders. :-)

Cheers,
Martin

On 15-08-24 02:01 AM, Jack Bowers wrote:
> Hello all, thanks to those who responded!
>
> I have just moved to a new country and still have no internet connection
> outside of work so pardon the delayed response…
>
>
> Martin, regarding your reasoning being the complications that arise in
> the data model if you allow <relation> to be anywhere:
>
> I see your point, but if the point in having <relation> in the
> guidelines then it should be usable for the purposes it is meant, which
> currently it is only partially so; i.e when using automated process or
> encoding short list manually.
>
> So, in an automated process with a clearly organized pre-existing
> dataset you can obviously just have the <listRelation> automatically
> output separate from the related components and everything is fine..
>
> However, if someone is encoding a list of places or whatever of
> significant length by hand and they want to use <relation> but are
> burdened with putting it at the end separate from the data, this is very
> difficult, unpleasant and time consuming to have to scroll up and down
> constantly. In many cases the the most likely result will be that they
> do not use the element at all. (/As perfectly timed evidence to this
> point, see Martin de la Iglesia’s recent reply ;-)/ )
>
> <link> is allowed to occur outside the content of <linkGrp> and in any
> ordering if I’m not mistaken, so why can’t a similar modeling be applied
> to <relation>?.
>
> To (preemptively) stave off any possible implications that <link> just
> be used and <relation> deprecated, I think <relation> is important
> because of the semantics of it’s attributes (@active; @mutual; @
> passive), the implications of which are more specific than <link>... I
> think <relation> is an important element in bridging TEI with RDF
> ontological data as well (/though I know of course that’s not the only
> way/)...
>
> So I personally would much prefer to have <relation> in a liberalized
> occurrence context similar to <link> and it does seem like I am not the
> only one who thinks this way...
>
> Should I write a ticket for this to make the case formally?
>
> (/Anyone willing to assist with a proposed re-model/ticket co-authoring
> would be very much appreciated/! ;-) )
>
> Cheers!
>
> Jack
>
>
>
>> On Aug 21, 2015, at 7:12 PM, Martin Holmes <[log in to unmask]
>> <mailto:[log in to unmask]>> wrote:
>>
>> On 15-08-21 09:37 AM, BODARD Gabriel wrote:
>>> 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?)
>>
>> I think the simple answer to that is that it makes content models
>> difficult to define and maintain. If it doesn't matter where something
>> goes, then you might as well specify a fixed place for it, so that
>> everyone knows where to find it; and that helps keep your content
>> model simpler. If position is significant, then there are arguments to
>> be made about the content models based on that significance.
>>
>> Cheers,
>> Martin
>>
>>> G
>>>
>>> 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?
>>>>>
>>>>>
>>>
>>>
>