[tei-council] "global" @source [was Re: Fwd: RE: @resp]

Martin Holmes mholmes at uvic.ca
Thu May 30 12:15:44 EDT 2013


I have an open ticket on @resp:

<http://sourceforge.net/p/tei/feature-requests/443/>

which I haven't had time to proceed with. I do have it in hand, though.

Cheers,
Martin

On 13-05-30 07:42 AM, James Cummings wrote:
> On 30/05/13 15:31, Gabriel Bodard wrote:
>> I don't think there's a ticket for this yet (please correct me if I've
>> missed it) but this question (of making @source (a) available more
>> widely than just on quote, egXML, etc., and (b) expanding its semantics
>> to the source of a piece of information, datum, translation, encoding
>> rather than just a quotation) is intimately tied up with
>> https://sourceforge.net/p/tei/feature-requests/443/ (on making @resp
>> more widely available).
>>
>> As I understand and remember it, we had gotten as far as agreeing that
>> both @resp and @source would usefully be more widely available than they
>> currently are. (We would probably also agree that neither of these
>> should be technically global attributes.) But how do we go forward to a
>> decision somewhere in between the two extremes?
>
> Yes, I seem to remember specifically quite some resistance to the
> idea that either of these be truly made global.
>
>> I think the way forward is to collect (in a ticket? in a wiki page? in
>> emails to the list/to me?) specific and documented use-cases of elements
>> which we need to be able to attribute to a particular encoder, or whose
>> content we need to attribute to a bibliographical source somewhere. From
>> these examples, we should try to come up with a coherent proposal for
>> the extension of both of these attributes.
>
> I've not personally got any use-cases to hand where I've felt I
> needed this, but agree with some of the arguments for extending
> it more widely. I'm really not sure how to implement that
> sensibly or where to draw the line in this case.
>
> -James
>
>>
>> Does this seem reasonable? Does anyone else want to collate this
>> information? Any preference as to where/how we do this? (Do we need a
>> new ticket alongside FR 443, or should we have both conversations
>> together in there?)
>>
>> Gabby
>>
>> On 02/02/2013 14:39, Gabriel Bodard wrote:
>>> Surely the definition of @source only contains the word "quotation"
>>> because it was designed for <q>, <quote>, etc. If we consider it a
>>> suitable mechanism for indicating the bibliographic source of a set of
>>> dimensions, for example, then that definition would have to change.
>>>
>>> [Aside: when marking up apparatus criticus, I use @resp to point to
>>> bibiographical references for readings and conjectures, not to persons.
>>> Does this mean @source would be more appropriate for this use?]
>>>
>>> G
>>>
>>> On 02/02/2013 19:14, James Cummings wrote:
>>>> Hi all,
>>>>
>>>> I can see att.responsibility being made available more generally
>>>> (I'm very reluctant to say globally until I've really sat down
>>>> and thought about the implications of that...) I understand it
>>>> may have once(?) been intended for editorial intrusions into a
>>>> transcription or edition but believe we've generalised out such
>>>> indications to refer to any markup or encoding.  Maybe it was
>>>> always intended as such.
>>>>
>>>> I can see arguments for @source (which is where this started
>>>> right?) on more things and that att.editLike should get it from
>>>> the att.source class.  But, I think we have to be careful that it
>>>> is available only on things which can be classified as containing
>>>> a 'quotation or citation' in some way since it "provides a
>>>> pointer to the bibliographical source from which a quotation or
>>>> citation is drawn."  Either that, or this definition would have
>>>> to be changed.
>>>>
>>>> Why does egXML get @source and not eg incidentally?
>>>>
>>>> -James
>>>>
>>>>
>>>>
>>>> On 02/02/13 18:27, Gabriel Bodard wrote:
>>>>> Seconded.
>>>>>
>>>>> I (as I pointed out in another venue recently) am regularly surprised to
>>>>> re-learn that @resp isn't global already. I can't imagine any element
>>>>> that I would not want to be able to say either who is responsible for
>>>>> the decisions it represents, or from what publication the information so
>>>>> tagged comes. (Certainly everything in msDesc, as well as editLike, at
>>>>> the very least.)
>>>>>
>>>>> G
>>>>>
>>>>> On 02/02/2013 17:07, Martin Holmes wrote:
>>>>>> On 13-02-02 02:47 AM, Lou Burnard wrote:
>>>>>>> Tomaz has a good point here. Presumably att.editLike should inherit the
>>>>>>> @source attribute from att.sourced ?
>>>>>>>
>>>>>>> I am waiting for someone to want @source to be added to att.global...
>>>>>>
>>>>>> And that would be me. I can imagine a use-case for virtually any
>>>>>> element. I'd also like @resp to be global, incidentally -- same
>>>>>> argument. I need to assign responsibility for <pron>, <seg>, <def> and
>>>>>> all sorts of other bits and pieces in a dictionary project I'm working on.
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------- Original Message --------
>>>>>>> Subject: RE: @resp
>>>>>>> Date: Sat, 2 Feb 2013 10:09:19 +0100
>>>>>>> From: Tomaz Erjavec <tomaz.erjavec at ijs.si>
>>>>>>> To: 'Lou Burnard' <lou.burnard at retired.ox.ac.uk>
>>>>>>> CC: <TEI-L at LISTSERV.BROWN.EDU>
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> @source is the only attribute defined in the att.source class (with
>>>>>>> quote q writing egXML as members).
>>>>>>> But @source is also defined (directly, not via class) as an attribute of
>>>>>>> att.editLike, so in fact quite a lot of other elements already have it.
>>>>>>> Is there any particular reason that it is defined in two different
>>>>>>> places? I'd say it only confuses things.
>>>>>>> And, yes, it would probably be a good idea to have source on even more
>>>>>>> elements, e.g. person and all its descendants.
>>>>>>> Best,
>>>>>>> Tomaž
>>>>>>>
>>>>>>> -
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)


More information about the tei-council mailing list