Re: [tei-council] xenodata/@scope

You obviously feel very strongly about this, Syd. Let me try to articulate why I’m uneasy about @scope. If I’m processing a document that has xenodata in it, I’m going to need to answer several questions: 1) What is this? 2) How am I supposed to read it? 3) What do I do with the information therein? @scope doesn’t actually help me with any of these. The only thing it does, I suppose, is help me disambiguate if I have several xenodata elements that focus on different things. But what does that use-case look like? Why are we jumping to that one first? Is the point so that I can decide whether or not to read the thing in the first place? That seems like a premature optimization to me.* In my example #1, I suppose the scope is the source, but that’s because the catalog record was about the object that the TEI document is about, yes? Not because it was the source for the TEI document. Hmm. Ambiguity. Technically, I suppose, being the source for the TEI, it's just as much about the TEI doc, or at least its content. Of course, the TEI documents I’m thinking of as a use case don’t even have transcriptions, so it wouldn’t occur to me to use that option. In example #2, I have no idea what the precise relationship of this putative JSON object is to my document. It’s relevant somehow. Read it if you want to know what’s in it. And I guess that’s my main point: if you want to know what the xenodata says, you have to read it. @source doesn’t provide me any useful information for deciding what to do with it except in some theoretical scenario. If the attribute is optional, "other" doesn’t really make sense as a value, does it? If it’s "other" I should just not use @scope. "Both" is problematic too, if we think we might ever have more than two options. I note the original request asks only for a place to put non-TEI metadata, not for a way to say what it’s about: https://github.com/TEIC/TEI/issues/453 https://github.com/TEIC/TEI/issues/453 I guess your last paragraph is a point of philosophy where we disagree. I think no advice is better than bad advice and that it’s easier to add stuff people might decide they need than to take away things they don’t use. I’d rather start minimalist and build up than try to guess at what users might want. The latter isn’t so bad in software, where getting rid of features is easy; it’s hard in standards. * IIRC the guidelines for dealing with a desire to optimize early go thusly: 1) Think twice before you do it. 2) Then don’t do it.

On Oct 6, 2015, at 16:50 , Syd Bauman wrote:

I think Martin is correct about Hugh's examples. Example #1, if it uses @scope, would be scope=source. Example #2, if it uses @scope, would be scope=other. Two caveats:

1) I agree, we *may* find there is demand for further granularization of "other". At which time, we should likely further granularize it. But for now, it is just a suggested values list, encoders can create their own more granular values.

2) Hugh's example #2b is not something I personally would not encode with <xenoData>. I'd just stick the mods:whatever elements in my bibliography. #2a is a bit trickier, because I don't know what the relationship between Hugh's GeoJSON and the <place> element is. But perhaps the place/@source would do, perhaps there is no need for a 1-to-1 mapping between the GeoJSON and the <place>s (in which case <xenoData> with scope=other or no @scope would do), or perhaps there is a need for a closer relationship, in which case you should whatever you would have done before <xenoData> came along, or use the decls mechanism.[1]

FC> My position is that we should discuss this with more deeply at FC> the f2f, and abstain from including this att in the release, for FC> the moment.

My instinct (which I might be talked out of) is that releasing <xenoData> without @scope is more harmful than not releasing it. That is, I'd prefer to remove <xenoData> from P5 than have it there without a TEI-defined mechanism for distinguishing "about the source" from "about the TEI document". (Although that mechanism need not be @scope.)

HC> I'm not sure what it's useful for though.

It is useful for differentiating *what* the metadata is *about*. There will be a lot processes that are going to be very happy they don't have to dive into a given <xenoData> because they're looking for metadata about one, not the other.

HC> I also think "transcription" is too specific a term.

I kinda agree, but none of us were able to come up with a better one.

HC> I do think users will want to have ways to characterize the contents HC> of <xenodata>, but @scope is just sort of a guess at what they HC> might need.

First, users will probably want to characterize their <xenoData>s, and they have @type (and @subtype) with which to do so. Second @scope is not a guess about that characterization. It is the answer for the obvious need to differentiate metadata about the source from metadata about the TEI file. (For crying out loud, there are plenty of other bits of metadata in the <teiHeader> for which it is clearly spelled out in the Guidelines whether it is about the TEI file or the source document ... why wouldn't we want at least that level of specificity here?)

HC> We'd be better off finding out what those needs are HC> before committing to a solution.

As alluded to above, I couldn't disagree more. The TEI _Guidelines_ are supposed to provide _guidance_. We know it is often important to know whether a bit of metadata is about the TEI document (as with <fileDesc> or <correspDesc>) or about the source of that TEI document (as with <sourceDesc> or <revisionDesc>). Since we know that, we should provide users a way to say so. To *not* provide that mechanism means that some users will develop their own mechanisms to say so (which will be incompatible with each other) and others simply won't say (which, admittedly, is still the case with the proposed <xenoData>, as we don't have the guts to make it a required attribute). Why let the world devolve into 2 dozen different ways of saying the same thing?

Note ---- [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? -- 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