Now and again in our conversations about this, we've mentioned the potential ambiguity between what's metadata and what's the body of an annotation. It seems to me this is about how comfortable we are with the ambiguity of annotation data / metadata. I am not sure why it's necessary to separate data from metadata in annotations, which are not themselves documents but more like connectors. Also, because the elements we are using in Hugh's model are semantically meaningful and carry their own combinations of data and metadata, I think we're already being clear enough about the relationships among ptr, note, and respStmt.So I'm in favor of the simpler of the two models, not requiring annMeta or annBody. The simpler model should be perfectly easy to parse depending on what people's interests are in processing annotations.Cheers,ElisaOn Sun, Aug 16, 2020 at 12:04 PM Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:_______________________________________________Thanks for the explanation. I won't ask why, if this WADM is just a vague hand waving gesture of a model, rather than one with a concrete XML expression, we are bothering with it. But I will ask you to reconsider the use of xml:id on the examples: are these <respStmt> things really meant to be unique? can we really limit sydb to make only one annotation per document?
On 16/08/2020 16:55, Nicholas Cole wrote:
OK. You’ve persuaded me that we might want to group things in ways that aren’t a ‘Body’. Let’s go with the simpler form. N From: Tei-council <tei-council-bounces@lists.tei-c.org> on behalf of Hugh Cayless <philomousos@gmail.com> Date: Sunday, 16 August 2020 at 16:53 To: TEI Council <tei-council@lists.tei-c.org> Subject: Re: [Tei-council] Annotations and impasses I prefer the opposite, but for the same reasons :-). The only other tags I could ever envision allowing as WADM:body analogs are things like <ab>, <p>, <seg>, etc. When we come around to doing really useful annotations that say things like "This string in the text could have a <persName> tag wrapped around it", I think we'll need something new that emphatically isn't a WADM:body. But as I said, while I think <annBody> is pointless, I'd be willing to live with it. Hugh On Sun, Aug 16, 2020 at 11:33 AM Nicholas Cole <nicholas.cole@history.ox.ac.uk<mailto:nicholas.cole@history.ox.ac.uk>> wrote: If we are chasing WADM compatibility, I prefer the second (i.e. a tag to group for Body) for clarity and because I think we will regret any other choice later — if it turns out that there could ever be a tag that could be both in body and in ‘metadata’. It also makes parsing for export simpler. If we are not absolutely chasing WADM compatibility, then I prefer the first option. N On 16 Aug 2020, at 16:27, Hugh Cayless <philomousos@gmail.com<mailto:philomousos@gmail.com>> wrote: Hi All, Since we essentially have today to make the go/no-go decision for getting Annotations into this release. We seem to be deadlocked in a couple of ways, and I would like to see if we can un-jam things. Syd and I are arguing over whether annotations should look like: <annotation xml:id="anno9" target="http://example.org/image1 http://example.org/image2"> <respStmt xml:id="HAC"> <resp>creator</resp> <persName>Hugh Cayless</persName> </respStmt> <ptr target="http://example.org/description1"/> <note>tag1</note> </annotation> or <annotation xml:id="anno9" target="http://example.org/image1 http://example.org/image2"> <annMeta> <respStmt xml:id="SB"> <resp>creator</resp> <persName>Syd Bauman</persName> </respStmt> </annMeta> <annBody> <ptr target="http://example.org/description1"/> <note>tag1</note> </annBody> </annotation> Syd's argument (and you should correct me if I'm misrepresenting your opinion, Syd) is that it's cleaner to partition things this way and we might want in the future to say virtually any TEI element could be an annotation body. My counter to this is that we set out here to implement the Web Annotation Data Model (or parts of it at least) in TEI, and that WADM doesn't have extra containers for annotation metadata or bodies. Further, WADM doesn't do specialized body types. They have text and they have URIs. I'm certainly in favor of adding useful features to TEI annotations, but if we want to do that in the next round of work on annotations, we'll have to do it by adding new TEI functionality (probably via new elements), and I don't think partitioning the content of annotation will buy us anything. It might make it worse, because the extra-sparkly new TEI functionality won't be compatible with WADM:body and therefore probably shouldn't go in an <annBody> element. To compound this, Laurent seems to say that WADM was only ever meant to be an inspiration and actual interoperability with Web Annotation wasn't a goal they had in mind in requesting this feature. I'm just going to go cry for a bit...excuse me. Ok. I will sum up: I would really like to have WADM compatibility this year because I have things I want to do with it. My proposal is that we proceed with WADM-compatible annotations and then begin work on more powerful TEI annotations. I would like to keep the content model of <annotation> as simple and as close to WADM as possible, but I won't pout if I'm voted down on that. What do you all think? Hugh _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org<mailto:Tei-council@lists.tei-c.org> http://lists.lists.tei-c.org/mailman/listinfo/tei-council
_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council
--_______________________________________________Elisa Beshero-Bondar, PhDProgram Chair of Digital Media, Arts, and Technology | Professor of Digital Humanities | Director of the Digital Humanities Lab at Penn State Erie, The Behrend CollegeDevelopment site: https://newtfire.org
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council