I'm in two minds about this. As it is, I think @source is useful and the absence of some such mechanism will be a serious deficiency for <xenoData>. On the other hand, I'd like to avoid releasing something which we later wish to revoke because we come up with something better. As far as Hugh's examples go:

1) I generated my TEI (particularly its metadata/header) from another source, and I want to capture that source.

Ignoring the parenthetical bit, surely this is @scope="source"?

2) I have related data in another format, maybe GeoJSON for mentioned places, or MODS records for my bibliography that I want to embed.

@source="other", no? Or, alternatively, you might be arguing that <listBibl>, <listPlace> and <listPerson> belong in att.declaring, so you can point from them to your <xenoData>. If so, that's not a problem with <xenoData> or @source. Are we worried that the set of suggested values for @scope is too weak? If so, they're only suggested, and the list can be expanded later. Are we, on the other hand, worried that this attribute (combined with @type and @subtype, and the declaring infrastructure) is still insufficient, and something else is needed? Cheers, Martin On 15-10-06 08:12 AM, Fabio Ciotti wrote:

I have some doubts as well, in a past mail exchange about <xeno> I suggested some similar use cases advocating for a more granular way to associate a metadata set with part of the TEI doc. My position is that we should discuss this with more deeply at the f2f, and abstain from including this att in the release, for the moment.

f

2015-10-06 16:43 GMT+02:00 Hugh Cayless :

...

I wanted to ask, before it’s too late, whether we’re all happy with @scope on <xenodata>. I’m not very fond of it, to be honest. I might use xenodata in the following scenarios:

1) I generated my TEI (particularly its metadata/header) from another source, and I want to capture that source. 2) I have related data in another format, maybe GeoJSON for mentioned places, or MODS records for my bibliography that I want to embed.

In nether case would @scope really help me...I was under the impression that we were going to defer categorizing xenodata until we had requests from people using it.

What do we think?

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

I agree with Hugh that the current spec is prematurely precise. Maybe removing the <valList> and substituting a more vague <desc> such as "may be used to characterise the scope of the associated xenodata, for example as relating to the source of the document, or to the document itself, or some other topic." would be a reasonable step forward in our current state of ignorance? On 06/10/15 17:02, Hugh Cayless wrote:

I'm not sure what it's useful for though. If I understand it, @scope="source" means the xenodata is about the thing the <sourceDesc> is about; "transcription" means it's about the TEI document, which I suppose includes the xenodata itself, so that's nice and recursive. I also think "transcription" is too specific a term.

I do think users will want to have ways to characterize the contents of <xenodata>, but @scope is just sort of a guess at what they might need. We'd be better off finding out what those needs are before committing to a solution.

On Tue, Oct 6, 2015 at 11:41 AM, Martin Holmes wrote:

...

I'm in two minds about this. As it is, I think @source is useful and the absence of some such mechanism will be a serious deficiency for <xenoData>. On the other hand, I'd like to avoid releasing something which we later wish to revoke because we come up with something better.

As far as Hugh's examples go:

1) I generated my TEI (particularly its metadata/header) from another

...

source, and I want to capture that source.

Ignoring the parenthetical bit, surely this is @scope="source"?

2) I have related data in

...

another format, maybe GeoJSON for mentioned places, or MODS records for my bibliography that I want to embed.

@source="other", no? Or, alternatively, you might be arguing that <listBibl>, <listPlace> and <listPerson> belong in att.declaring, so you can point from them to your <xenoData>. If so, that's not a problem with <xenoData> or @source.

Are we worried that the set of suggested values for @scope is too weak? If so, they're only suggested, and the list can be expanded later. Are we, on the other hand, worried that this attribute (combined with @type and @subtype, and the declaring infrastructure) is still insufficient, and something else is needed?

Cheers, Martin

On 15-10-06 08:12 AM, Fabio Ciotti wrote:

...

I have some doubts as well, in a past mail exchange about <xeno> I suggested some similar use cases advocating for a more granular way to associate a metadata set with part of the TEI doc. My position is that we should discuss this with more deeply at the f2f, and abstain from including this att in the release, for the moment.

f

2015-10-06 16:43 GMT+02:00 Hugh Cayless :

I wanted to ask, before it’s too late, whether we’re all happy with

...

@scope on <xenodata>. I’m not very fond of it, to be honest. I might use xenodata in the following scenarios:

1) I generated my TEI (particularly its metadata/header) from another source, and I want to capture that source. 2) I have related data in another format, maybe GeoJSON for mentioned places, or MODS records for my bibliography that I want to embed.

In nether case would @scope really help me...I was under the impression that we were going to defer categorizing xenodata until we had requests from people using it.

What do we think?

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

Are you suggesting a content model like element xenoData { att.global.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., att.global.rendition.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., att.global.linking.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., att.global.analytic.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., att.global.facs.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., att.global.change.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., att.global.responsibility.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., att.declarable.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., att.typed.attributes http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/..., desc?, text | macro.anyXML http://teijenkins.hcmc.uvic.ca/job/TEIP5-Documentation/ws/P5/Guidelines-web/...* } Lou? I'd be ok with that, actually. I'll point out too that it has @type and @subtype already, so there are ways to characterize it.

Hugh was responding to a different post, Lou. But on this issue, I have not `git pull`ed in your removal of the comment, and the HTML I build looks fine; as does the HTML at http://teijenkins.hcmc.uvic.ca/job/TEIP5/2176/artifact/P5/release/doc/tei-p5... which was built at 12:01 (my time?) today, so also pre-dates the removal. (Not that I object to removing the comment, which was mostly there for your benefit; I'm wondering if the descrepancy between your build and Mr. Jenkin's build represents a problem.)

All I was suggesting that the comment at the start of the current content model ... should be removed cos it looks daft in the HTML output Never mind. I've removed it myself!

You can see whatever Jenkins last used in its build by browsing its workspace: http://teijenkins.hcmc.uvic.ca/job/TEIP5/ws/P5/Source/Specs/xenoData.xml You can see the comment is not there. Cheers, Martin On 15-10-06 03:34 PM, Lou Burnard wrote:

If I look at https://github.com/TEIC/TEI/commit/732f62beb12903153ac1b07cf4f7099a1519809d I see the comment, and my removal of it.

But no matter, it's not there in the build on Jenkins, so that's fine.

On 06/10/15 23:13, Syd Bauman wrote:

...

Hugh was responding to a different post, Lou. But on this issue, I have not `git pull`ed in your removal of the comment, and the HTML I build looks fine; as does the HTML at

http://teijenkins.hcmc.uvic.ca/job/TEIP5/2176/artifact/P5/release/doc/tei-p5...

which was built at 12:01 (my time?) today, so also pre-dates the removal. (Not that I object to removing the comment, which was mostly there for your benefit; I'm wondering if the descrepancy between your build and Mr. Jenkin's build represents a problem.)

...

All I was suggesting that the comment at the start of the current content model ... should be removed cos it looks daft in the HTML output Never mind. I've removed it myself!

Lou, Martin -- I think you're missing my point. There is something different between the HTML Lou is building (in which comments inside <content> are displayed somehow) and the HTML Mr. Jenkins and I are building (in which comments inside <content> are summarily dropped -- after all, they are comments). If I had to hazard a guess I would say Lou is using different, partially PureODDified, stylesheets. But if that's *not* the case, this is something we may want to investigate.

So, either the comment was added to the github repo after Jenkins took his copy, or Jenkins took his copy after I removed it. As I said, so long as it's not there in the release, I really don't mind!

But Martin, I was refering to a specific build, which (I believe) had the comments in the <content>:

http://teijenkins.hcmc.uvic.ca/job/TEIP5/2176/artifact/P5/release/doc/tei-p5...

Jenkins seems to have done its last build from an XML document that did not contain the comment, so we don't actually know whether it's behaving like your setup or like Lou's.

But since nobody wants the comment anyway, we could just forget about this. If it's really important to find out, we could add a comment to a content model and see what Jenkins does with it.

Good. So we have two positive results: comment was removed, and we now know we need to tweak the processing of PureODD content so that comments and PIs (at least, PIs aimed at ourselves like <?winita?>) get dropped.

Ah, yes, thanks. You are right: I am using a version of the Stylesheets in which the content of the <content> element is assumed to be pure ODD, and since it's pure ODD, I display everything in it without processing it. So comments get displayed too.

But the comment shouldn't be there anyway, and now it isn't. So hoorah.

On 15-10-06 02:03 PM, Syd Bauman wrote:

<xenoData> already does not permit any elements from the TEI namespace. (It also does not permit the teix:egXML element.)

This is because macro.anyXML can *not* include elements from TEI.

Of course you're right. Sorry, not thinking. Cheers, Martin

As currently conceived, we would *never*, under any circumstances, permit a tei:desc as a child of <xenoData> to describe its purpose/target/function in vanilla TEI. (We can't stop a user from customizing to do that, of course.)

Thus there is no ambiguity here.

But that utter lack of ambiguity also allows us to change our conception, and to permit model.labelLike as a 1st child of <xenoData> for the very purpose of indicating or describing its purpose/target/function.

I don't think I like it. It adds complexity where there may be no need for it -- here I think it may make sense to wait and see if there is any demand. I suspect @type and @subtype will be enough. But I am certainly willing and interested to hear other points of view.

...

I think given what <xenoData> is really for -- here be non-TEI -- it shouldn't have TEI children. You'll tell me that anyXML can include TEI perfectly well, which is true, but I don't think that's the same thing as adding something that's specifically TEI to its content model. How would we distinguish a <desc> that's added as a child of <xenoData> to describe its purpose/target/function from a <desc> that's "part of" the xenoData itself, but happens to be TEI? I don't like the ambiguity there.

Also, if we are going to modify this spec, please remove the bit of the <content> which is commented out : it appears in the HTML spec and looks confusing. On 06/10/15 17:02, Hugh Cayless wrote:

I'm not sure what it's useful for though. If I understand it, @scope="source" means the xenodata is about the thing the <sourceDesc> is about; "transcription" means it's about the TEI document, which I suppose includes the xenodata itself, so that's nice and recursive. I also think "transcription" is too specific a term.

I do think users will want to have ways to characterize the contents of <xenodata>, but @scope is just sort of a guess at what they might need. We'd be better off finding out what those needs are before committing to a solution.

On Tue, Oct 6, 2015 at 11:41 AM, Martin Holmes wrote:

...

I'm in two minds about this. As it is, I think @source is useful and the absence of some such mechanism will be a serious deficiency for <xenoData>. On the other hand, I'd like to avoid releasing something which we later wish to revoke because we come up with something better.

As far as Hugh's examples go:

1) I generated my TEI (particularly its metadata/header) from another

...

source, and I want to capture that source.

Ignoring the parenthetical bit, surely this is @scope="source"?

2) I have related data in

...

another format, maybe GeoJSON for mentioned places, or MODS records for my bibliography that I want to embed.

@source="other", no? Or, alternatively, you might be arguing that <listBibl>, <listPlace> and <listPerson> belong in att.declaring, so you can point from them to your <xenoData>. If so, that's not a problem with <xenoData> or @source.

Are we worried that the set of suggested values for @scope is too weak? If so, they're only suggested, and the list can be expanded later. Are we, on the other hand, worried that this attribute (combined with @type and @subtype, and the declaring infrastructure) is still insufficient, and something else is needed?

Cheers, Martin

On 15-10-06 08:12 AM, Fabio Ciotti wrote:

...

I have some doubts as well, in a past mail exchange about <xeno> I suggested some similar use cases advocating for a more granular way to associate a metadata set with part of the TEI doc. My position is that we should discuss this with more deeply at the f2f, and abstain from including this att in the release, for the moment.

f

2015-10-06 16:43 GMT+02:00 Hugh Cayless :

I wanted to ask, before it’s too late, whether we’re all happy with

...

@scope on <xenodata>. I’m not very fond of it, to be honest. I might use xenodata in the following scenarios:

1) I generated my TEI (particularly its metadata/header) from another source, and I want to capture that source. 2) I have related data in another format, maybe GeoJSON for mentioned places, or MODS records for my bibliography that I want to embed.

In nether case would @scope really help me...I was under the impression that we were going to defer categorizing xenodata until we had requests from people using it.

What do we think?

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

On 15-10-06 02:07 PM, Syd Bauman wrote:

...

Also, if we are going to modify this spec, please remove the bit of the <content> which is commented out : it appears in the HTML spec and looks confusing.

What? No comments appear in the tagdoc I build locally (except in the 3rd example).

(Can someone remind me how to see the most recent build on Jenkins?)

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel... Cheers, Martin

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?

On 15-10-06 04:04 PM, Lou Burnard wrote:

...

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?

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.

I think the problem Syd is pointing at is that <listPlace>, <listPerson> etc. are typically thought of as metadata elements, so declaring elements in <text> might point up to them as metadata. But now we have an additional metadata component which can itself apply to bits of the header metadata; so there's a potential need for lots of elements that we usually think of as metadata (<listPlace> etc.) to be able to point to <xenoData>, as well as to be pointed at by e.g. <div>. I think this is a genuine issue. What's in att.declaring is largely arbitrary -- I can say that a <ref> is associated with a <listPerson> element, but not that a <persName> is associated with a <person> (at least, not through the declaration mechanism). With the advent of <xenoData>, if it's widely adopted, I'd expect to see a number of requests for elements to be added to att.declaring, among them many header elements. Hugh's case (<listPlace> with associated GeoJSON in <xenoData>) is a good example. Cheers, Martin

On 15-10-06 04:31 PM, Lou Burnard wrote:

...

I think the problem Syd is pointing at is that <listPlace>, <listPerson> etc. are typically thought of as metadata elements, so declaring elements in <text> might point up to them as metadata. But now we have an additional metadata component which can itself apply to bits of the header metadata; so there's a potential need for lots of elements that we usually think of as metadata (<listPlace> etc.) to be able to point to <xenoData>, as well as to be pointed at by e.g. <div>.

I thought the purpose of xenoData was to cordon off non-TEI data? If we're going to start allowing pointers into it, life is going to get complicated.

Not pointers into it: pointers to it. We've already allowed that by making it att.declarable and giving it an @xml:id.

...

I think this is a genuine issue. What's in att.declaring is largely arbitrary -- I can say that a <ref> is associated with a <listPerson> element, but not that a <persName> is associated with a <person> (at least, not through the declaration mechanism).

I agree that it's a bit hard to see why some elements are declaring (notably ref and ptr): that might quite well be a bug. The way to associate a <persName> with a <person> is of course with a @ref, as you well know, not a @decls: the two mechanisms are different.

...

With the advent of <xenoData>, if it's widely adopted, I'd expect to see a number of requests for elements to be added to att.declaring, among them many header elements. Hugh's case (<listPlace> with associated GeoJSON in <xenoData>) is a good example.

What would be the practical use of doing such a thing?

To specify that this listPlace is generated from, or parallel to, or the source of, or somehow related to, that piece of e.g. GeoJSON. Seems straightforward to me. I might have three blocks of GeoJSON and three listPlace elements; surely it makes sense to be able to say which goes with which? Cheers, Martin

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

@corresp is so generic, though. I feel that some semantic sugar would help. On Thu, Oct 8, 2015 at 9:51 AM, 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

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

If what's being suggested is that @corresp be used for the same purpose as @decls, then I think we ought to be talking about broadening the scope (sorry) of @decls, as I suggested before. Let's not have two mechanisms being recommended for doing the same job. Cheers, Martin On 15-10-08 07:15 AM, Lou Burnard wrote:

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

I may be misunderstanding what you are agreeing with, but the distinction between @decls and @corresp is pretty clear to me. As I said somewhere below "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". whereas @corresp, if we applied it to <xenoData> and to some other TEI metadata element (not necessarily a declaring one) would simply mean that the two elements correspond, i.e. that they supply metadata about the same thing I suspect that a situation is quite likely to arise in which we cannot determine what TEI element corresponds (in this sense) with a particular chunk of <xenodata> -- not least because a single chunk of xenodata may concern itself with aspects that the TEI separates into different elements. Yes @corresp can take multiple values, but even so. On 08/10/15 16:23, Raffaele Viglianti wrote:

Agreed. In this case @decls is not adequate because the referred metadata is not "understood to *apply* to the element bearing this attribute". (emphasis mine; this is what clearly separates @corresp from @decl). The question is more whether we can use @scope as a way to correlate xenoData and TEI metadata, therefore avoiding not-very-useful values like "source" or "transcription". The only issue I see with this is that there would be no way of indicating a scope that is not already covered by TEI metadata, but, as I said earlier, this may not be a bad thing.

Raff

On Thu, Oct 8, 2015 at 11:11 AM, Martin Holmes wrote:

...

If what's being suggested is that @corresp be used for the same purpose as @decls, then I think we ought to be talking about broadening the scope (sorry) of @decls, as I suggested before. Let's not have two mechanisms being recommended for doing the same job.

Cheers, Martin

On 15-10-08 07:15 AM, Lou Burnard wrote:

...

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

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

On Thu, Oct 8, 2015 at 12:10 PM, Syd Bauman wrote:

if it pointed to <sourceDesc> does that mean that the (non-TEI) metadata is about "the source of this TEI document" or about the <sourceDesc> itself?

That's why I wouldn't want to use @corresp, but a dedicated attribute that indicates that the scope of these xenoData has the same *scope* as the metadata in *this* header element. The basic idea is using the taxanomy built-in in the TEI header as scopes for the xenoData. Instead of having scope="source" have scope="#sourceDesc". If this won't fly, I would at least suggest to base out eventual valList for @scope on what's already modelled in the header.

The <fileDesc> doesn't point to what its metadata applies to, the <revisionDesc> doesn't point to what its metadata applies to. Why should <xenoData> be different? Well, because we're collapsing two different uses (<non-TEI-description-of-source> and <non-TEI-description-of-this-file>; or /TEI/teiHeader/fileDesc/sourceDesc/xenoData and /TEI/teiHeader/fileDesc/xenoData; or whatever) into one, and differentiating them with an attribute.

<xenoData> is not intended to be a dumping ground where you get to put your JPEG page images or JSON FOAF data or KML snippets. It's intended to be a place to put extracts of either the (non-TEI) metadata you used to generate your TEI header (but want to keep in its original form for some reason), or the (non-TEI) metadata you generated from your TEI header (and want to keep around for later processes, presumably).

...

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

Re:base64 encoding JPG ... uh yes. That is what we have binaryObject for. Otherwise, agreed. James -- Dr James Cummings, Academic IT, University of Oxford -----Original Message----- From: Hugh Cayless [philomousos@gmail.com] Received: Thursday, 08 Oct 2015, 12:47 To: Syd Bauman [s.bauman@neu.edu]; TEI Council [tei-council@lists.tei-c.org] Subject: Re: [tei-council] xenodata/@scope Syd, I think your conception of what xenoData is for is much narrower than mine. I would use it for related data that for some reason doesn't quite fit into my TEI. That might be because it isn't TEI, or even XML, or it might be because TEI doesn't quite do the trick for representing it. I agree that Base64 encoding your JPEG and bunging it in there would be dumb, but maybe having a manifest of linked images in a non-TEI format might not be. A FOAF representation of the social network represented in my document might be fine too. The problem statement in the original ticket begins "People sometimes want to attach metadata to a TEI document that doesn't fit into an existing header element." Isn't that what we should implement, having agreed that's not a bad idea? On Thu, Oct 8, 2015 at 12:10 PM, Syd Bauman wrote:

Raff --

No, it would not help at all to make @scope a pointer to a specific element, or to use some other attribute to do the same thing. But worse, it would cause confusion, because (e.g.) if it pointed to <sourceDesc> does that mean that the (non-TEI) metadata is about "the source of this TEI document" or about the <sourceDesc> itself?

The <fileDesc> doesn't point to what its metadata applies to, the <revisionDesc> doesn't point to what its metadata applies to. Why should <xenoData> be different? Well, because we're collapsing two different uses (<non-TEI-description-of-source> and <non-TEI-description-of-this-file>; or /TEI/teiHeader/fileDesc/sourceDesc/xenoData and /TEI/teiHeader/fileDesc/xenoData; or whatever) into one, and differentiating them with an attribute.

<xenoData> is not intended to be a dumping ground where you get to put your JPEG page images or JSON FOAF data or KML snippets. It's intended to be a place to put extracts of either the (non-TEI) metadata you used to generate your TEI header (but want to keep in its original form for some reason), or the (non-TEI) metadata you generated from your TEI header (and want to keep around for later processes, presumably).

...

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

<xenoData> is not intended to be a dumping ground where you get to put your JPEG page images or JSON FOAF data or KML snippets. It's intended to be a place to put extracts of either the (non-TEI) metadata you used to generate your TEI header (but want to keep in its original form for some reason), or the (non-TEI) metadata you generated from your TEI header (and want to keep around for later processes, presumably).

That's not how I see it, to be honest. I would put exactly those sorts of things in it (with the exception of JPEGs). I would hope that any data in <xenoData> would be mirrored in some form or another in the teiHeader, but that may not always be practical. Cheers, Martin On 15-10-08 09:10 AM, Syd Bauman wrote:

Raff --

No, it would not help at all to make @scope a pointer to a specific element, or to use some other attribute to do the same thing. But worse, it would cause confusion, because (e.g.) if it pointed to <sourceDesc> does that mean that the (non-TEI) metadata is about "the source of this TEI document" or about the <sourceDesc> itself?

The <fileDesc> doesn't point to what its metadata applies to, the <revisionDesc> doesn't point to what its metadata applies to. Why should <xenoData> be different? Well, because we're collapsing two different uses (<non-TEI-description-of-source> and <non-TEI-description-of-this-file>; or /TEI/teiHeader/fileDesc/sourceDesc/xenoData and /TEI/teiHeader/fileDesc/xenoData; or whatever) into one, and differentiating them with an attribute.

<xenoData> is not intended to be a dumping ground where you get to put your JPEG page images or JSON FOAF data or KML snippets. It's intended to be a place to put extracts of either the (non-TEI) metadata you used to generate your TEI header (but want to keep in its original form for some reason), or the (non-TEI) metadata you generated from your TEI header (and want to keep around for later processes, presumably).

...

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.

Hi Fabio, Many thanks for laying out some real use-cases that will help us see the bigger picture. I think #3, #4, and #5 all present an issue that we can make a straightforward decision on: Is it OK/encouraged/supported to point between subelements inside the XML content of a <xenoData> and elements in the TEI content? I would say: Yes, why not, when the <xenoData> contains XML. Since there's no knowing what xenoData is, the only thing we can give examples of really is pointing from TEI to @xml:id attributes inside <xenoData> (or using similar pointing mechanisms such as XPointer). But if the other flavour of XML has its own pointing attributes, they could perfectly well be used with the caveat that the encoder understands them and can cause them to be processed correctly. When the <xenoData> content is not XML, it's also possible (although very messy) to use e.g. XPath to point from a TEI element to it. I don't think we'd ever want to encourage this or give examples of it, though. I would, though, tend to recommend that where possible, each block of non-TEI data be in its own <xenoData> element, and that any pointing take place between that element and the TEI content. That's simpler and cleaner, if it's practical. Cheers, Martin On 15-10-08 12:27 PM, Fabio Ciotti wrote:

I share the wider conception of <xenoData>, and that is why I would like a more fine grained way to assert the possible relationships between the metadata it contains and their data objects (that doesn't mean we need to add necessarily new constructs, we can also adapt existing ones - accepting the risk to extend their semantic and intended usage). I suggest some use cases of possible metadata sets that could go there:

1) I have a set of MODS (DC, VRA, etc) data that replicate the (eventually incomplete) data in <sourceDesc>

How can I state this explicitly? @corresp? @sameAs?

2) Similarly, I have a set of Premis metadata that substitute or implement <revisionDesc> (we can imagine a lot of variation on this theme)

3) I have a MIX technical description of images inside <graphic> elements. How can I link each <graphic> with its related metadata? Are we sure @decls is really apt at this

4) a complication of 3) I have a set of MIX technical description for various kind of image formats referred by <graphic>? Shall the TEI enforce that each single set of MIX data should go in a separate <xeno> container? If not how can a single <graphic> element refer to its own set of MIX?

5) I have a non XML rdf triple that define a SKOS based terminology of elements encoded with <term> (or whatever elements). How can I associate each <term> with its SKOS definition?

...

I am not saying that we should support explicitly all the possible use case but, you know, when you open the door of hell, never know who is coming out. I think that most uses of TEI is guided by purely pragmatic concerns, and the Guidelines cannot control how people behave. But we should at least suggest the intended (or best practice) usage - and conversely forbid the not intended one - in a set of fundamental situations, and make this usage as simple and clear as possible. This is why I think that the @scope attribute we have imagined so far is either not enough granular or redundant (inasmuch as all <teiHeader> data are intended to apply to the XML file and its content, and I could argue that this is true also for <sourceDesc>).

f

2015-10-08 19:21 GMT+02:00 Martin Holmes :

...

...

<xenoData> is not intended to be a dumping ground where you get to put your JPEG page images or JSON FOAF data or KML snippets. It's intended to be a place to put extracts of either the (non-TEI) metadata you used to generate your TEI header (but want to keep in its original form for some reason), or the (non-TEI) metadata you generated from your TEI header (and want to keep around for later processes, presumably).

That's not how I see it, to be honest. I would put exactly those sorts of things in it (with the exception of JPEGs). I would hope that any data in <xenoData> would be mirrored in some form or another in the teiHeader, but that may not always be practical.

Cheers, Martin

On 15-10-08 09:10 AM, Syd Bauman wrote:

...

Raff --

No, it would not help at all to make @scope a pointer to a specific element, or to use some other attribute to do the same thing. But worse, it would cause confusion, because (e.g.) if it pointed to <sourceDesc> does that mean that the (non-TEI) metadata is about "the source of this TEI document" or about the <sourceDesc> itself?

The <fileDesc> doesn't point to what its metadata applies to, the <revisionDesc> doesn't point to what its metadata applies to. Why should <xenoData> be different? Well, because we're collapsing two different uses (<non-TEI-description-of-source> and <non-TEI-description-of-this-file>; or /TEI/teiHeader/fileDesc/sourceDesc/xenoData and /TEI/teiHeader/fileDesc/xenoData; or whatever) into one, and differentiating them with an attribute.

<xenoData> is not intended to be a dumping ground where you get to put your JPEG page images or JSON FOAF data or KML snippets. It's intended to be a place to put extracts of either the (non-TEI) metadata you used to generate your TEI header (but want to keep in its original form for some reason), or the (non-TEI) metadata you generated from your TEI header (and want to keep around for later processes, presumably).

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.

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

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