[tei-council] Proposal <idno> coverage -SF 2493417

[Lou Burnard]

Daniel Paul O'Donnell wrote:
> 
> As a middle ground, could not a solution be to use key point at a
> different structure that contains the real pointer information? I.e. is
> not Peter's complaint that there is too much information for @key? And
> is a solution for that not to point to something where the multiple bits
> of information can be collected?

No, I'm sorry, but this doesn't really help much. Where would that 
somewhere else be? There isn't anywhere else!

As designed, @key and @ref are intended to point to the "canonical" home 
of information about a person, place etc. Note the word "the": I think 
that implies there's only one such canonical home.

Now we have the problem that there are different *ways* of identifying 
that canonical home. You say "nldai:info:eu-repo/dai/nl/12456454" and I 
say  "openid:https://me.yahoo.com/johndoe61" These are both, like the 
many children of the <location> element, ways of getting to the right 
place, whereever that might be. In a TEI-only world, it would be a 
<person> element, and we'd point directly to it by means of @ref. But we 
could also say, in the "openid" world, you get to it like this; in the 
"nldai" world you get to it like this... etc.

The suggestion of using @key to supply many such values is a strictly 
short-term solution. It works because in TEI-land we don't care what 
values you supply for @key, as long as we can infer that identical 
values mean you're talking about the same platonic entity . So note that 
@key="foo bar" is *not* talking about the same entity as either 
@key="foo" or @key="bar". That seems another argument against this being 
the best possible solution, if we really think that "nlda" and "openid" 
are equally good ways of getting to where we want to be, to add to the 
formal ones Peter has already summarized. The right way of handling 
these things is clearly to treat them as alternative identifiers, rather 
than pointers, and that's what <idno> is for.

In the medium/long term therefore we need to find a better way of 
integrating multiple <idno>s into the current structures. That involves 
a careful re-consideration of the existing bibl structures, I'm afraid. 
Again.


> 
> Sebastian said that we'd need to go through the whole TEI looking for
> similar issues. But it seems to me that we've already established a
> principle of trying to offload complex information from textflow to
> structures elsewhere in the document, i.e. in all our personography
> work.
> 
> Again, sorry if this has been raised and dismissed.
> 
> On Sun, 2009-01-25 at 18:13 +0000, Lou Burnard wrote:
>> I don't think anyone disagrees that the multiple <idno> solution is 
>> better. But the @key value solution does do the job -- and doesn't 
>> require any changes at all in the current system.
>>
>> Peter Boot wrote:
>>> Sebastian Rahtz schreef:
>>>> in the short-term, I am unconvinced that @key cannot do the
>>>> job for Laurent
>>> Well, some reasons which haven't been mentioned up to now:
>>>
>>> If the choice is between
>>>
>>>    key="nldai:info:eu-repo/dai/nl/12456454
>>>          openid:https://me.yahoo.com/johndoe61"
>>>
>>> and
>>>
>>>    <idno type="nldai">info:eu-repo/dai/nl/12456454</idno>
>>>    <idno type="openid">https://me.yahoo.com/johndoe61</idno>
>>>
>>> I would favour the idno element over the key attribute because
>>>
>>> * the @type attribute's values can be very straightforwardly
>>>   constricted to an known list of values, which is harder to
>>>   do when multiple schemes and values are stored as part of a
>>>   single text string (in the @key attribute);
>>> * both the values and the schemes are straightforward to access
>>>   in XSLT when using the <idno> solution;
>>> * a rule-of-thumb in xml design is for me: if something has
>>>   properties of its own (in this case, the identifier's scheme),
>>>   it should be an element rather than an attribute.
>>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>