Re: [tei-council] xenodata/@scope

I agree: this does seem like a plausible case for @corresp On 08/10/15 14:51, Hugh Cayless wrote:

Maybe we can already do that with @corresp though? I was wondering the same sort of thing...

On Thu, Oct 8, 2015 at 9:44 AM, Raffaele Viglianti < raffaeleviglianti@gmail.com> wrote:

...

Would it help to make @scope a reference to a specific TEI element in the header, à la @decls? A reference to sourceDesc or msDesc would unambiguously indicate what the xenoData are about (or is equivalent / alternative to). The downside is that there must be corresponding TEI metadata for this to work, but maybe that's not a bad thing?

Disclaimer: I'm jumping into this late, so apologies if this suggestion may appear naive at this point in the conversation.

Raff

On Thu, Oct 8, 2015 at 12:30 AM, Syd Bauman wrote:

...

...

My suggested rewording for the <desc> of scope would do this [allow differentiation between "about the source" from "about the TEI document"], I claim, without going to the lengths of specifying values for @scope. Yes, but without being machine-actionable, and thus much less usefully.

...

I think it would be a shame not to include xenoData in this release at all. I disagree. I think this is a case of better to keep one's mouth shut and let people think we're fools ...

...

This is just nitpicking, but surely the <revisionDesc> is about the TEI document, not its source? And <correspDesc> is definitely not about the TEI document but about the real world events reflected by it. You're right, of course. I had reversed 'em. But the point remains.

...

...

Why let the world devolve into 2 dozen different ways of saying the same thing? Ah well, that's the TEI way... Inasmuch as that's true, it's a bad thing. A very bad thing, which decreases the utility and usefulness of TEI for many, and I daresay has probably even driven some users away from TEI entirely.

When equally expressive methods A and B already exist in community practice, there is an argument to be made for codifying them both in the _Guidelines_. (One I would probably argue against, but that's another story.) When there is no pre-existing practice, most users simply want to be told which way to do it, so their practice will match that of others.

Case in point: I think it was at a dinner in Ann Arbor (not sure) when a group of us were chatting, and complaints that the TEI allowed <listPerson> anywhere were rampant. People just wanted TEI to pick one or two places where <listPerson> is supposed to go and leave it at that.

In this case there is not a pre-existing community practice. No one cares what method they use. Many, if not most, users won't even think about the issue unless it is mentioned in the Guidelines. But it is an important issue, or at least I believe it is, and as of a few weeks ago y'all agreed.

But once a user realizes that it can be useful to know whether a chunk of metadata is about the TEI file or its source, she will just want to be told how to specify it in a machine-processable way.

Yes, TEI users often need a great degree of flexibility in their encoding in order to express that which is important to them about their documents. But when it doesn't matter whether a concept is expressed as A or B, we, the TEI Council, are supposed to tell the user community "use A, do not use B". It's our job.

...

...

[1] For now you'd have to put each set of <place>s that had different metadata in the GeoJSON into its own <div> so said <div> could have an @decls that points to the <xenoData>. That said, can someone explain to me why <listPlace> is in att.declarable but not att.declaring? I was quite baffled by this question for a while. Declarable elements are provided so that declaring elements like <div> can independently select from a number of possibly relevant chunks of metadata provided together in the header. The mechanism is for fine tuning the standard rule that says "what's in the header applies to everything that the header is attached to". It's not for doing the sorts of things you seem to be considering here, if I understand correctly. Certainly I don't see how a hierarchy of declarability (which you seem to be suggesting) would work. You've lost me, Lou. (Which probably means I lost you, first. :-)

I was just trying to give Hugh some mechanism for embedding "related data in GeoJSON for mentioned places"[1]; and then wondering aloud, as a completely separate issue, why <listPlace> can have @default (thus implying that different lists of places might be relevant to different parts of my document -- while not at all insane, a bit implausible), but cannot have @decls, which would allow you to easily express that two different <listPlace>s were derived from different sources, e.g.

No hierarchy of declarability intended. (Although I did mean to imply that if a <div> has a @decls, then the metadata pointed to by that @decls applies to the contents of that <div> (unless overridden by another @decls).)

Note ---- [1] And please, don't think for a moment that I think embedding GeoJSON data related to a mentioned place in your TEI document is a good idea. That's what @key (or @ref with a local tag URI) is for, after all, no? But Hugh seems to want to do it, and (unlike XML formats) he can't just stick it anywhere he wants, he needs to put it in a <xenoData>. (At least, I can't think of where else he might put it.) -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived