Talk:Cofibration

Cleanup

I have made several major edits. There was at least one substantial error (conflating semisimplicial and simplicial sets), there may be others remaining. — Preceding unsigned comment added by Gadget142 (talk • contribs) 20:55, 17 June 2023 (UTC)

This page tries to deal with both the narrow case of cofibrations in Top and the general case of cofibrations in an arbitrary model category. This is inappropriate in my opinion. The basic problem is that the concept of a cofibration in Top can be discussed independently in a way that draws only on standard notions of point set topology, but I don't think that "cofibration in a general model category" can be easily discussed outside of the page on model categories. After all, the concept of a cofibration in a model category does not make sense without reference to the weak equivalences and fibrations of the model category and axioms, so it is really difficult to discuss it. "What is the definition of a cofibration in a model category?" This question cannot be easily answered on its own, one should instead address the question "What is a model category?" We should not give examples of cofibrations in model categories; we should give examples of model structures on categories, in the page on model categories.

Another problem is that the definitions are sufficiently different that pedagogically it is confusing. Yes, there is a model structure on Top such that the closed Hurewicz cofibrations are the cofibrations in the model structure, but this is a difficult result due to Strom that few people understand anymore, and moreover there is confusion in the literature over this due to erroneous proofs! This is a lot for the neophyte to grapple with, I think, so care is required in explaining the relationship.

As a side note please exercise care where there are subtleties arising from Top vs the category of compactly generated weakly hausdorf spaces. — Preceding unsigned comment added by Gadget142 (talk • contribs) 20:44, 17 June 2023 (UTC)

Subset

I think A must be a subset of X.

- Well then i is simply an inclusion map. It is better in my opinion to consider a mapping cylinder of A ajoined to X instead of just (X x 0) U (A x I).

In the third basic theorem, I don't think the biconditional always holds. I think A may have to be closed for the reverse direction to hold.

A is always closed. Follows from retraction or extension property. We may need Hausdorff though, but I am pretty certain we do not. —Preceding unsigned comment added by 128.12.72.244 (talk) 03:26, 2 October 2007 (UTC)

One always needs Hausdorff for something like this. —Preceding unsigned comment added by Polfbroekstraat (talk • contribs) 01:33, 2 March 2008 (UTC)

Additional condition

I added the compactly generated condition for a cofibration to be closed inclusion. May's book page 42 seems to say this is so, but maybe he means an arbitrary space. I haven't found a proof yet but I'll get back if I do. Money is tight (talk) 15:19, 24 January 2011 (UTC)

May prefaces chapter 6 with a reminder that all spaces are to be taken as compactly generated. i.e. A, X, Y. Exactly how this definition might be altered if they are not is not stated. User:Linas (talk) 01:44, 16 August 2013 (UTC)

Closed inclusion

The "definition" given in the text (closed inclusion = injective with closed image) is misleading. The subspace that is included also needs to carry the subspace topology! I suggest writing "inclusion of a closed subspace" instead of "closed inclusion" to avoid this ambiguity. --134.99.156.114 (talk) 08:01, 6 May 2015 (UTC)

Indeed, the current presentation is highly misleading (this isn't isolated to Wikipedia). For example, the obvious map from [0,1) is injective with closed image, but it clearly doesn't satisfy the HEP. Cofibrations should be certain types of maps, not pairs of a space and subspace (I think). If you're going to mix the two, then clear and careful explanation should be given. But the treatment on Wikipedia at the moment is to define cofibrations as certain kind of maps satisfying the HEP, which on the corresponding page is a property of pairs of spaces. 2A02:C7D:BC32:5200:2C09:F07C:D9B0:14F2 (talk) 17:34, 18 July 2017 (UTC)

Merge proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

no consensus

---

On 02:11, 12 December 2015‎ User:TakuyaMurata proposed that this article, and the Homotopy extension property be merged, but did not provide a reason. Discuss below.

• Don't merge. These are clearly different topics, despite the fact that they are often discussed together. Merging would just confuse the discussion. 67.198.37.16 (talk) 06:20, 5 September 2016 (UTC)
• The reason for the merger proposal is that there are a lot of overlaps between the two articles; merging the two does not mean the two concepts are identical. Is there any instance when "homotopy extension property" is discussed outside the context of a cofibration? -- Taku (talk) 09:12, 7 September 2016 (UTC)

Yes, well, I understand that. But I think its OK to have multiple smaller articles with overlapping, duplicated content, rather than one big, one-size-fits-all article. I have a lot of trouble reading big long articles, my eyes glaze over; they are daunting. Short articles are just easy-pickins. As [[User::Ronnie Brown]] points out, there is certainly a lot more that can be said about either topic; it would be best if all these articles used the same notation, at least, that is more important. 67.198.37.16 (talk) 09:04, 24 October 2016 (UTC)

If the discussion becomes substantial, we can always break up the article. There are advantages and disadvantages for having separate articles on closely connected topics. Right now, the most unfortunate drawback is that the readers are being required to read the "homotopy lifting" article unless he is already familiar with the concept of cofibration and homotopy lifting. One constant criticism on math articles in Wikipedia is that they are (or seem to be) written for those who already know the definition as well as the applications. I think this article is a good example of this. The cheapest solution is to simply merge the two articles. Anyway, this is just a proposal and I don't insist on the implementation. -- Taku (talk) 06:23, 29 October 2016 (UTC)

(non-admin closure)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.