[tei-council] repeating and typing tei:provenance

Lou Burnard lou.burnard at retired.ox.ac.uk
Mon Sep 26 07:12:41 EDT 2011


I wonder whether simply adding @type is the right answer in this case? I 
would prefer to see a more semantically meaningful attribute added 
explicitly to the provenance element.

"type" of a provenance might relate to any number of things -- its 
reliability, the kind of authority behind it, on what temporal basis 
it's made, etc. For example, suppose at some time a manuscript was in a 
collection which had a policy of checking up on it every 6 months. You 
might decide either to enter lots of provenance records saying 
effectively "it was taken out and dusted", or you might decide just to 
record a single provenance record for the whole time, including the info 
that dusting had been carried out every six months. Wouldn't these be of 
two different "type"s ("periodic" and "summary") as well?

Your examples of intended use ("found", "moved", "observed", "lost", 
"destroyed", "restored" etc.) are fine for the case where you can map 
each provenance to a single event, but this is not the only way that 
<provenance> might be used, and therefore not the only way they might be 
typed.

How about @eventType or even just @event ? (You could also add a value 
such as "multiple" or "summary" of course)

As regards updating the schema without updating the documentation -- I 
consider that to be an entirely understandable desire, but one which 
should be resisted as far as is humanly possible! Certainly the ticket 
should not be closed until the examples in the documentation have been 
corrected.


On 26/09/11 11:32, Gabriel Bodard wrote:
> In this case, should I just go ahead and add att.typed to tei:provenance
> and commit it to SVN? The other changes discussed in that ticket refer
> to the guidelines only and have no schema implications.
>
> Cheers,
>
> G
>
> On 2011-09-24 05:43, Laurent Romary wrote:
>> This is a very good move with respect to this ticket. Please go ahead (and agree with Elena, I don't think we need a new FR).
>> Laurent
>>
>> Le 23 sept. 2011 à 18:05, Pierazzo, Elena a écrit :
>>
>>> Hi Gabby,
>>>
>>> You have my blessing, in case you needed it. I don't think there is the
>>> need of another FR as the possibility of allowing multiple<provenance>   is
>>> contemplated within the initial description of the ticket.
>>> Best
>>> Elena
>>>
>>>
>>>
>>> On 23/09/2011 16:55, "Bodard, Gabriel"<gabriel.bodard at kcl.ac.uk>   wrote:
>>>
>>>> Some Council members will already have seen the ticket posted by Lou a
>>>> couple days ago (http://purl.com/TEI/FR/3411976) re the conflict between
>>>> the definition of tei:provenance, "descriptive or other information
>>>> concerning *a single identifiable episode* during the history of a
>>>> manuscript" on the one hand, and on the other examples (including that
>>>> at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/MS.html#mshy) in
>>>> which mutiple episodes are described in a single provenance.
>>>>
>>>> I pointed out, in support of the examples over the definition, that
>>>> provenance includes among its possible children tei:listEvent, and that
>>>> some projects have already used this to represent different episodes in
>>>> a manuscript's history within a single tei:provenance.
>>>>
>>>> The consensus on this ticket however seems to be that the definition is
>>>> correct, the examples should be emended, and multiple episodes should be
>>>> represented by repeated, dated tei:provenance elements in tei:history.
>>>> It has also been suggested that provenance is a specialization of
>>>> tei"event, so the usage is fine.
>>>>
>>>> If that is the case, then I'd like to propose (does this need another
>>>> ticket?) that as well as changes to the guidelines and correction of
>>>> examples, the provenance element should allow att.typed (as event does),
>>>> so that multiple provenances in the history of a single manuscript or
>>>> object can be typed ("found", "moved", "observed", "lost", "destroyed",
>>>> "restored" etc.), and looser subtypes can be used to differentiate
>>>> between different kinds of loss, for example. (We were in the process of
>>>> writing up a controlled set of values for tei:event/@type for the EpiDoc
>>>> guidelines, with the intention of leaving @subtype unconstrained.)
>>>>
>>>> Does anyone object to this proposal? Should I put up a new FR ticket for
>>>> it? I'd like to be able to let the EpiDoc community know what we've
>>>> decided so it can be written into our ODD in advance of the next TEI
>>>> release, if possible.
>>>>
>>>> Thanks,
>>>>
>>>> Gabby
>>>>
>>>> --
>>>> Dr Gabriel BODARD
>>>> (Research Associate in Digital Epigraphy)
>>>>
>>>> Department of Digital Humanities
>>>> King's College London
>>>> 26-29 Drury Lane
>>>> London WC2B 5RL
>>>>
>>>> Email: gabriel.bodard at kcl.ac.uk
>>>> Tel: +44 (0)20 7848 1388
>>>> Fax: +44 (0)20 7848 2980
>>>>
>>>> http://www.digitalclassicist.org/
>>>> http://www.currentepigraphy.org/
>>>> _______________________________________________
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>
>> Laurent Romary
>> INRIA&   HUB-IDSL
>> laurent.romary at inria.fr
>>
>>
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>



More information about the tei-council mailing list