[tei-council] repeating and typing tei:provenance

Mon Sep 26 09:39:05 EDT 2011

To answer your second point first: I would certainly never change the 
schema in a way that rendered guidance wrong without fixing the latter 
too. In this case, I think, the changes to the guidelines are 
independent of the small schema change I proposed. (I wasn't proposing 
to close the ticket, in any case.)

Does anyone have feelings about how to change the examples involving 
provenance? New examples? Changing the current ones to multiple (typed) 
provenances? Any prose need adding too?

To answer your first point second: I can see the attraction of a more 
semantic attribute including the concept of event, but I still prefer 
att.typed for two reasons: (1) I'd see the typing of provenance elements 
in parallel to the typing of origPlace elements, and using the same 
attributes for both would make sense; (2) we would like to use these 
attributes (in both cases) with controlled values for @type, to 
encourage interoperability within a family of projects, and free text 
for @subtype, to allow greater expressiveness for individual projects.

For that matter, do we mind if people use @type for different kinds of 
typology on provenance, so long as they don't by doing so neglect other 
attributes that are more appropriate (@cert for reliability, @resp for 
authority, @when etc. for temporal details, etc.)? If we give the 
example of using @type/@subtype for types of provenance event (or more 
properly states between events), that should be the default usage anyway.

In fact, I'd probably go so far as to argue for the inclusion of 
@subtype even if Council consensus prefers Lou's suggestion of @eventType.

On 2011-09-26 12:12, Lou Burnard wrote:
> 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
>>
>
> _______________________________________________
> 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

-- 
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/